Perceptions are Reality!

Recently, I had a long phone conversation with a gentleman who knows what he is talking about: Michael Krigsman. His core interest are the causes and prevention of IT failures in the enterprise software industry. His background in developing tools and processes for software implementations makes him a well respected authority on the subject. He has turned his experience into a tool that will provide an early warning before IT projects go downhill. It is not just another project management tool, but uses people’s perceptions to realign projects with goals. I monitor perceptions to ensure the success of goal-oriented, adaptive processes. No wonder that we got along well.

Michael also quotes Peter Kretzman who mirrors some of my previous posts:

“First off, I’ve never seen a big project fail specifically because of technology. Ever. And few IT veterans will disagree with me. Instead, failures nearly always go back to poor communication, murky goals, inadequate management, or mismatched expectations.  People issues, in other words.”

The typical solution to this problem is to call for more and rigid project management, best practices or a methodology. But project management issues can’t be solved by methodology, because if they could be then we would not still have up to 70% of projects either failing or not delivering as planned. Any step to improve this even slightly would be fantastic, but it rather seems to get worse as projects get bigger and more complex. Therefore the trend is to buy industry standard, off-the-shelf, out-of-the-box applications and align the business to work like the software. Oops: It is easier to change a business organization than to create a piece of software that supports as business as needed? Are we being serious??? Shouldn’t all involved be tarred, feathered and chased out of town?

The direct cost of failed IT projects in businesses all over the world must be in the hundreds of billions. The follow-on cost of lacking IT functionality to the economy must be staggering.

Michael describes the core issues of big IT projects in his post The Devils Triangle. It is a triangle of buyers, system integrators (SI) and consultants having different, hidden agendas. In most large projects, software vendors are represented through a systems integrator, who will not only make the choice of software – mostly for reasons unknown to the buyer – but also plan and execute the implementation. Another party has not been mentioned –  analysts! To purely cover their back, no CIO or SI would dare to bring a software product into a project that has not been favorably covered by the analyst community. So how in the world can it still all go wrong? Well, read his post! I have voiced and written similar views in the past, but eventually decided to focus on a technology solution.

Wait a moment: If the problem is not caused by technology, why am I saying that technology can reduce those project issues. Why am I developing a communications and process platform if its implementation project can still be messed up by people? Well, if the technology requires less manpower, skills and elapsed time to implement then the people problems will be reduced. A model-preserving application definition that uses an evolutionary, iterative implementation style reduces scope creep and the danger of obsolescence. It solves the problem partially. But it is our experience that IT and business both still need to unlearn the old ways.  If  business and IT are empowered to adapt applications to needs without big projects, the first rollout does not have to contain everything. Weekly improvement cycles become possible! Faster iteration, more innovation! Less complex analysis, less misalignments. Less people, less problems. But yes, that is not yet enough.

Michael and me agree on one substantial problem that is at the same time an important part of the solution: PERCEPTIONS! I have been writing a lot about business strategy lately, pointing out that processes aren’t optimized when they are executed as designed, but only when the customer perceives them as satisfactory. I am not just talking about delivering a defined outcome, but understanding how bad perceptions are often created by a misalignment between marketing and execution. Happiness is a matter of managing expectations and it won’t be improved by fancy advertizing, a CRM database, or by social networking.

And because perceptions are hidden away in people’s heads, they can’t be managed in a project plan.  The bigger the project, the worse it gets. Each individual involved in the project may have a very different perception about the project’s target, progress and cost. Because we can’t control someone’s perceptions, the most we can expect is to understand them. That is Michael’s focus. He uses questionaires to define perception markers that point to project issues rather than monitoring project plan metrics. The whole project has to start with creating the right expectations and too often, these are already wrongly set, just to get the project off the ground. The only way to take care of this is by improving communications and by working towards a project (ideally business) culture of openness. While social networking might improve  communication, it does neither improve project transparency nor empowers to take action.

Technology is not the direct cause of project failures, but it is the people who chose complex target solutions that thus create the project nightmares. We should accept that we arrogantly overestimate our ability to manage people in large projects. Keep them small! We misjudge our ability to define a clear solution to a fuzzy problem. Make it flexible! It is the same kind of arrogance that we use when we think we can encode our human business interaction into flowcharts. Stay humble! We don’t have it all under control. Project planning as well as business processes have  to consider and support the irrational heuristics of perceptions, choices and decisionmaking. People simply aren’t logical, they are human!

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

Tagged with: , , , ,
Posted in Application Lifecycle, Business Architecture, IT Concepts, People Management
19 comments on “Perceptions are Reality!
  1. […] This post was mentioned on Twitter by TheBusinessArchitect, The Tech Gang. The Tech Gang said: #BusArch #News Perceptions are Reality! « Welcome to the Real (IT) World!: Filed under Application Lifecycle, Busi… […]


  2. […] Do we need ‘Jack-in-the-Box’ Software? I just posted on my ‘Real World’ blog about IT project failures under the title ‘Perceptions are Reality’. […]


  3. Love this post. Particularly…

    “…failures nearly always go back to poor communication, murky goals, inadequate management, or mismatched expectations. People issues, in other words.”

    Max I’d be very interested in any evidence or data behind your stat “70% of projects failing or not delivering”. I don’t disagree with this number at all – quite the reverse – just interested in its provenance.


  4. Max – compelling stuff – thanks, will study.

    You’re probably familiar with it, but one set of findings that blew us away was James Martin’s research which showed that *82% of the effort to fix defects was caused by erroneous requirements*. So you could surmise that, if you’re a CIO, 82% of the risk of losing your job comes from getting requirements wrong – sounds believable!

    And of course this has nothing to do with technology – it’s about human communication and (mis)understanding. Strange it is, then, that this aspect gets such relatively small attention from the industry?


  5. […] Perceptions – Max J. Pucher Project planning as well as business processes have to consider and support […]


  6. Matthew,

    Measuring statistics around project failure is very difficult, in part because failure is not a black or white “event.”

    More accurately, it is helpful to think in terms of degrees to which a project accomplishes stated (or desired) business goals within time and budget constraints.

    Nonetheless, studies consistently point to a range that states 30-70 percent of IT-related projects fail. Some studies go higher; others lower.

    Here is one example of a study that claims 68% failure rate:

    In my view, the actual number of failed projects is less important than the obvious level of waste and inefficiency associated with IT projects. Simply looking at direct costs alone, the level of waste is staggering. Add opportunity cost, and number skyrockets.


  7. Michael, thank you, great stuff. Indeed, “the level of waste is staggering”.

    We’re on a mission to improve understanding between IT and the business Your work is tremendous validation that we’re on the right mission…


  8. Matthew, thanks so much for your comments


  9. David Lewis says:

    How do you overcome the interpreted nature of a persons perception of their perception e.g. bias? How do you quantify the nature of a groups perceived reality in order to reshape perceptions?


    • David, thanks for reading and commenting.

      Why would you want to overcome something that is a core principle of nature? Why would you need to quantify a groups perceived reality and why would you want to reshape their perceptions. Which is the RIGHT perception? Yours? Someone elses? Human decision bias is not a fault, but a mechanisms to support fast decision making under uncertainty (Gigerenzer, Kahnemann, This is essential as we have always uncertainty. All information must be interpreted as you need an a priori ontology model to describe the entities on which you want to observe. The measurement (perception9 process is always at least inaccurate if not pure assumption. There is no fact as such but just information to be PERCEIVED as correct and reproducable.

      When you say: ‘This is fact.’ then all you say is that you BELIEVE your perception to be factual. But that is it. It is not fact to anyone else with a different perception model. When we communicate or when we analyze that concept has to be always on our mind.

      So what we need is a bit more humble acceptance that all our grand knowledge is just belief – regardless if science or religion.

      All the best, Max


      • David Lewis says:

        I aggree that bias is inherent and I didnt infer otherwise; this however is a very different issue (for me at least). For example there numerous types of bias some of which are short lived (e.g. only influencing a perecption when in a a particular context e.g. environment) and some of which are inherent, learnt or indoctrinated.

        The article Max published is crossing a number of subjects; perception, reality, perception of reality, perception of perception, bias, beliefs, communication etc.

        My observation from experience is that it’s not possible to accurately understand an individual’s perception…in the same way that when you put a sample under a microscope you cannot be sure that act of fixing or observing the sample doesn’t change the reality and/or your perception of the reality.

        For me just working towards the quantification/qualification of what has been referred to as a ‘shared reality’ in what could be many groups within the sample group is a good starting place as I don’t believe it is realistic to accurately understand an individual’s perception let alone a groups.


      • Thanks again, David. Agreed, we can’t understand perceptions. But for the person who has them they are real. They may be wrong from our perspective but that is irrelevant. We have to deal with those perceptions and not with what we think is right because people will make their decisions based on them. In addition they will be influenced by biases (Kahnemann, Tversky, Gigerenzer, but they might not be aware of that. That is basically my point: Make plans in relation to how do people think things are going versus what does your project or other statistical data show. It is not that hard: Ask them!


      • David Lewis says:

        I don’t agree with your approach as it is too reliant on very broad generalisations. Would be good to understand your methods as they are still unclear. Thanks


      • We can certainly agree to disagree, David. My method is to openly communicate and collaborate with people directly rather than relying on statistical analysis. Thanks for the time and discussion.


      • I must also add a final point here. Having studied and analyzed failure situations for many years, one conclusion is absolutely clear: mismatched expectations and poor communication are a fundamental cause of problems.

        As Max said, if you want to understand someone’s perception, there is no means that is superior to asking them. Now, people do not always communicate their perceptions and beliefs well, so some subtlety must inform how you ask. Regardless of the difficulty in gathering information, one should never minimize the role and importance of perception in understanding human behavior and action.


    • I have to agree with Max on this. Perception and bias are inherent, so that is not the problem. The real issue becomes finding a means to accurately understand individual and group perceptions. Usually, people do not want to reveal their real thinking (and therefore their actual bias). So, we need techniques to uncover what’s really going on.

      As Max points out, people act on the basis of their perceptions (including their biases). Gaining an accurate reading of a person’s perception (and therefore his or her bias) provides an opportunity to understand their actions and expectations.


      • David says:

        I totally agree re mismatched expectations however frame it in relation to an inconsistent understanding of the problem itself.

        I have a methodology that I have developed for PhD and in practise that bases its self in part on problem specification as a means to minimise some of this variance you describe.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Max J. Pucher
© 2007-19

by Max J. Pucher. All rights reserved.

Real World Statistics
  • 222,569 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 364 other followers

ISIS Papyrus on Twitter
%d bloggers like this: