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.

More in this category:
Next Post Previous post
Read 4919 times

Leave a comment

Related items

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations that your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, ironically they did not know since there was no procedure in place).

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

  • Strategic Alignment: The Key To Project Success

    Buy it now!

    Project success rates for many companies and government organizations are dismally low, yet executives never seem to look at the big picture. They continue to make adjustments in the way projects are run by addressing isolated problems. However, projects are part of a much larger system and should be addressed in that context. To do that, companies must define how their strategic plan will use people, projects, and technology to achieve their goals. This paper discusses one approach to make this happen.

  • Transforming Project Managers Into Project Leaders

    Buy it now!

    Project management has been accepted in many businesses as a discipline critical for continued growth. To improve project performance, companies have levied rules on how projects should be run, defined common reporting requirements for all projects, and pooled and shared their project management resources. Even with these functions, projects still struggle to meet the needs of the customer. In order to improve project outcomes, the way in which they are managed must change. Project managers must become leaders, paying more attention to soft skills, managing their stakeholders, and identifying solutions to organizational issues that are limiting project success. The following paper discusses techniques developed by the author to address these needs and improve project success rates.

  • Vision To Value: Creating Successful Projects Using Leadership

    Buy it now!

    Value: Rather than scope, schedule, and budget, value is the lynch-pin of project success. Although the former three constraints are key factors in project success, there is no guarantee that meeting these constraints will result in a positive outcome. Instead constantly tracking the value of the project and making adjustments to the triple constraints to attain sufficient value is critical. Arguably this is the project managers most critical deliverable in the project. It requires significant insight into the project’s customer and a thorough understanding of their needs versus their wants. Project managers have to be leaders (leading subordinates, leaders, and customers), be able to assign priorities based on a critical, objective view.

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
Flag of the United States Buy it in Canada Flag of the United Kingdom
Flag of Ireland Flag of Germany Flag of France
Flag of Italy Flag of the PRC
Flag of Japan
Book sellers worldwide.