ecaminc.com

  • Increase font size
  • Default font size
  • Decrease font size
Home Blog: Back From Red General Blog Technologists Are Never the Problem
E-mail Print PDF
RSS

Technologists Are Never the Problem

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

    Delicious Delicious
    Add to Technorati Favorites

    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.

    Tags: , ,

    Previous Blog Next Blog
 

Comments  

 
0 # Saurabh Gautam 2012-03-06 10:15
Sir, This is an excellent read. I wish that it catches eye of every manager,PL,TL. I abide by the SDLC process but its a repetitive cycle of requirements and development and sometimes when the code is laid; we get the news that the requirements have changed. This adds to the frustation of all the team members. But I would not say that the Customer didn't care about the phases under development; there lies the miscommunicatio n between what we"team" have been doing and what they"customer" are asking us to do.
Reply | Reply with quote | Quote
 
 
0 # Simon Rhodes 2012-03-08 00:28
His answer was wrong and you make good points - but it misses the fundemental issue - who owns the data.

It is the business - those who transform it have no - I say again absoluletly no responsibility for the data quality.

And it is data quality that is the cause of many project failures

@5imonRhodes
Reply | Reply with quote | Quote
 
 
0 # Samad Aidane 2012-03-24 14:43
Todd,

Great article as usual.

The attitude from the leadership of this organization is unfortunately not uncommon in some technical circles. Somehow, such technical roles believe in and live by the principle that overall success of a project is somebody else's job not theirs. Yet, they have such contempt for project managers and management in general. They folks be extremely uncooperative on projects and see project managers as an unnecessary overhead.

I worked with some of these roles. They prefer to live in a detached universe as if the world around them does not exist. On projects, they are only concerned about their own tasks not how they fit in the overall scheme of the project. They can care less about what’s happening around them. It is like that old saying: as long as the operation is successful, it does not matter if the patient dies. These are the same people that will surprise the project manager at the wrong time and place with pre-requisites and interdependenci es required for them to do their job. They take no responsibility. They are the same people who will blame the PM when the project is in trouble.

The sad thing is that they get away with this attitude because in most organizations this lack of accountability is an epidemic. This attitude unfortunately is what Project Managers have to deal with every day on projects. Ironically, this organization’s leadership does not see it but they clearly need your help to instill in their members attitudes and values that would make them productive citizens of project world.
Reply | Reply with quote | Quote
 

Add comment


Security code
Refresh


Who's Listening To Us...

Fortune/CNN Money logo
 
Forefront's logo
 
Enterprising CIO's logo
 
Slashdot's logo
 
The CEO Maagzine's logo
 

Read and Hear More...


Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada
Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany
Deutschland

Flag of France
France

Flag of Italy
Italia

Flag of the PRC
中國
Flag of Japan
日本の
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

Critical Chain
by Eliyahu Goldratt

Related Items