Sunday, 04 March 2012 00:00

Technologists Are Never the Problem

Rate this item
(0 votes)

I sent a note to professional organization's program director the other day asking if their group would be interested in hearing about methods to increase project success. The organization was for a technical group that worked with data transformation—a skill set used in every IT project I have ever been on. The reply came in a prompt, succinct, and sarcastic reply:

"We [sic] you please tell me just how this would ever relate to the members of our group. You obviously do not understand that we are not responsible for running the project."

I was taken aback. He failed to even proof his note properly. I was about to delete the email and move on when I decided that I should explore this a little further. I crafted the reply:

"Projects fail for a variety of reasons. Customer requirements, management support, too many defects, scope creep, etc. The technical team certainly has their part in that. Don't you think your members would want to know how to minimize their contribution. It would increase their longevity at their employers."

He never replied.

Inculpability's Safe Harbor

Therein lies the problem—if someone else is more culpable than him, it is not his problem. He is probably the same guy who, a few months later, will pout as his project is canceled, maligning management for doing a poor job of controlling the project (i.e., him) and now his vision has vaporized. This selfish, myopic view of responsibility kills hundreds of projects every month. It is never "my" responsibility. Programmers can add dozens of neat little features, architects can design bleeding-edge systems, customers can refuse to compromise, and quality analysts can test for every imaginable and remote situation, all remaining devoid of guilt, since the project's collapse was someone else's responsibility. Management tolerates, while leaders revile, this attitude.

Doing The Right Thing

Albeit, leadership should come from the top, in reality, anyone can step up to that position. They simply need to develop a few guiding principles for how they work with others. Thousands, if not millions, of these lists have been generated and I have seen only a few that I have disliked. I have found, though, that instilling the following principles in my teams are the most helpful.

    • The project's goal is value. Above everything else on the project, everyone must focus on the project's value. The value does not come from a great project plan, state-of-the-art technology, a bug free product, or delivering the project within scope, schedule, and budget. It comes from delivering a product that meets the customer's needs.
    • Understand how jobs interrelate. The project is not about you, it is about a product that a team is creating. Any member of that team can make or break a project. Adding the simplest of features, such as a print function (see the earlier Case Study in Will We Ever Learn? Lessons from The Mythical Man-Month), can drastically increase scope for the entire project and detract from the customer's value. Any change, addition or deletion, affects everyone associated with the project. What may seem like a simple addition for one group of the customers may be a bane for another.
    • Communicate With Teammates. No one can understand the complexity and conflicts of the desires, wants, and needs of a customer. It requires relentless communication with all the stakeholders. It is incumbent on every team member to assiduously communicate and question his or her assignments and activities. Success is a world devoid of dictatorial management and hierarchical communication. It requires leadership that trusts and allows people and teams to master their duties and work autonomously. This requires teams composed of the right individuals—people that comprehend the greater good and derive motivation from excellence—not perfection.
    • Do The Right Thing. Back in the days of old, I worked with the Digital Equipment Corporation where a stated value, looming larger than life, was "Do the right thing." This was at the core of their innovative spirit. The project team is morally bound to translate what the customer wants to what they need. This lies on the project team, since they are intimate with the details of building the project's product. They are the ones that can foresee the impact of a decision. This cannot, however, be performed in the project team's vacuum. There are conflicts between the wants and the needs and the customer must be part of every decision. This requires fluid and frequent interaction between the customer and the team. They must look at all the requested features and derive innovative and cost effective solutions for delivery. Although sounding like an Agile tenet, it is not exclusive to that methodology. It is at the foundation of any successful project.

The Right Answer

The subject of my opening example may be quite capable of working in the environment described above. Given a change in venue and allowing time for de-programming the accusative and blame-oriented style of management philosophies that he probably works in today, I will wager his work ethics would morph and he would be a valuable team member concerned and contributing to the success of the project. He simply needs the right leader. That leader could be you. It does not need to be your boss.

What Are Your Thoughts?

Please, share how you lead from within and what makes your projects excel.

Read 5818 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References