How to Resolve Conflict between Project Managers and IT Application Developers

By George Pitagorsky | Follow on Twitter!

Is there often tension between project managers and IT application developers?

Relationships are harmonious when the importance of project management and the challenges of software development are understood by all and when project managers and developers are committed to enabling one another to succeed.

There is conflict when there are unclear roles and responsibilities, misconceptions about the likelihood of getting system users and sponsors to definitively state requirements, evolving requirements, unrealistic expectations, and fuzzy quality standards.

When will you make an end?

There is a long history of conflict between the needs of project managers to have relatively stable and reliable project budgets and schedules vs developers who recognize the need for discovering requirements, designs and refining the product in an iterative process.

I am reminded of the scene from the Agony and the Ecstasy when in the 16th century Pope Julius II calls up to Michelangelo, on a scaffold painting the ceiling of the Sistine Chapel, "When will you make an end?”

Michelangelo responds, "When I am finished."

[VIDEO] Agile - DevOps and IT Service Management in the Land of Narnia

Control vs. Agility

Proponents of agile development approaches have long recognized that the control envisioned in traditional systems development life cycles with rigid divisions between phases gets in the way of delivering quality product and value. Project Managers recognize the need for controlling costs and delivering product to satisfy time constraints and the expectations of sponsors and clients. They also recognize the tendencies of developers to be overly perfectionistic and optimistic.

This is a conflict fueled by misunderstandings on both sides. When we look at the goals and objectives of both, they converge on the desire to satisfy stakeholders' expectations.

Firm Estimates

Project managers, program managers, product managers, project sponsors and clients want commitment to schedules and budgets. Delivery teams, whether they are artists, software developers, business analysts or others, know that schedules and deadlines in the face of the real world uncertainties they face are not entirely firm.

Uncertainty is the only certainty. Since schedules and budgets are based on estimates and estimates are based on assumptions, they are always subject to variance - to change. Some schedules are 99% likely to be met. Others have little chance of being met without ignoring quality.

To help to avoid or resolve conflict between project managers and developers, get everyone to acknowledge the reality of uncertainty and to qualify every estimate with its justified likelihood of being an accurate prediction of the outcome.

Waterfall vs. Agile

Software development is an engineering activity that requires the application of skills and technology to fulfill requirements. The greatest cause of uncertainty is evolving requirements. The traditional approach to engineering projects, the Waterfall approach, evolved out of experience in construction and product development focused on hardware - manufacturing equipment, automobiles, etc. - rather than software.

The Waterfall approach is documentation and control heavy and mandates that requirements be firmly defined before design and development activities take place. There are clearly divided Phases with checkpoints. At the checkpoint following the requirements definition phase, a fully documented set of requirements is expected to be reviewed and approved. Then, based on these approved requirements, developers determine a solution and develop it, while managing changes to the requirements as they occur.

This traditional Waterfall approach seeks to stabilize the process and make the outcome more predictable. If the requirements are a true reflection of what the end users, sponsors and clients want, then there will be few changes once the requirements have been approved. Since making changes during the development and implementation phases in construction and manufacturing projects is very expensive, it is a great advantage to have firm requirements up front and a tightly controlled change management process.

Agile and Iterative

As software development began to mature, many software (SW) engineers became convinced that the rigidity of the waterfall approach was not fully applicable to software development because:

1. It is very difficult and very time consuming to fully and firmly define requirements without stakeholders seeing what the product looks like

2. Excessive documentation does not add value

3. It is common that requirements change as stakeholders see the product

4. Tightly controlling and restricting change is time consuming and stops the natural flow between developers and their clients

5. It is far less costly to change software than it is to change hardware.

These SW engineers proposed an agile approach that integrated detailed requirements definition and development into a single iterative process that directly involved the people who define the requirements with the people who fulfill them on a single team.

[VIDEO] Coaching Agile Leaders

Both-and Thinking

Generally, we can say that project managers, with their desire for structure and predictability prefer the Waterfall approach and developers, with their desire to serve the users by finding out what they want and need and delivering it in an organic, interactive way. Tension arises because these approaches seem in conflict with one another.

In healthy relationships, tension signals the need for resolution. PMs and SW developers work together to find an approach that marries the best of both opposing approaches. They apply open minded Both-and thinking to find the best way to achieve the common goal of satisfying sponsors, clients and all other stakeholders.

Work Together to Craft a Hybrid Approach

Developers and project managers can work together as peers to craft a project approach that makes the most sense for their situation. They would lean more toward Waterfall when projects are large, complex, critical and regulated and toward agile when the product, the tools and availability of users/clients allow. Agile development can be embedded into a Waterfall approach, recognizing the need for defining business objectives, high level requirements and solution architecture before diving into iterative and agile development. Agile development, when done well, includes effective control over schedules, deliverables and effort.

A hybrid approach is far more likely to satisfy the need than rigid adherence to either pure Agile or Waterfall. Why waste your time and energy on conflict between waterfall or agile when you can have the right degree of both to suit your situation?