This paper was first published by ICFAI PRESS, Hyderabad in Projects & Profits Special Issue, March 2003, p18.

Published here May, 2003.

PART 1 | Introduction | Rapid Prototyping | Reasons Why Linearity Doesn't Work
People Problems | So What is the Answer? | Conclusions

People Problems

Scott Ambler, promoter of the Agile Data Method, provides some interesting insight into the software developer's working environment.[2]

Different visions and priorities. Developers focus on the specific needs of a single project and strive to work in isolation from the rest of the organization. Administrators focus on the overall needs of the enterprise, sometimes to the detriment of individual project teams, yet the scope priorities and issues of each are all different. To make matters worse, project stakeholders, including users all the way up to senior management, have varying priorities and visions as well.

Over specialization of roles. Specialists tend to be too narrowly focused. Because they are specialists, they may have difficulty relating to other professionals.

Process impedance mismatch. A number of recent approaches to software development advocate an incremental and iterative approach. However, many IS/IT managers still view the process as a serial or near-serial process. Consequently, there is a process mismatch necessitating a cultural and organizational change within the organization.

Technology impedance mismatch. Developers work with objects and components whereas data professionals work with databases and files. Software engineering principles form the underlying foundational paradigm for objects and components whereas set theory forms the underlying foundational paradigm for relational databases (by far the most popular database technology). Because the underlying paradigms are different the technologies don't work together as well as they should.

Ossified management. The technology and techniques used by IT professionals change rapidly. As managers progress up the corporate hierarchy they deal less with technology and more with people issues. It doesn't take long for their previous technical experience, on which they base decisions, to become obsolete.

Organizational challenges. Poor communications and "office politics" hurt development efforts just as badly as they hurt other enterprise efforts.

Inappropriate documentation. Either too much, or too little, documentation may prevail depending on management will. Too little and it becomes impossible to retrace earlier steps; too much and no one reads it.

Ineffective software architecture efforts. Software architecture is not a well established discipline, let alone a profession as in building construction. A lot of people simply don't know where to start. And, if they do, the resulting models are soon abandoned.

Ineffective development guidelines. Some organizations struggle to develop guidelines for all their IT people to work to. But, as with any guidelines including project management guidelines, some people are not aware of them; if they are they don't understand them; or if they do they consider them obsolete; or they are otherwise unwilling to follow them anyway.

Ineffective modeling efforts. Some people focus on a specific aspect to produce models that look very good only to discover that they do not reflect the real world, especially if past experience and practices are not factored into account.

Reasons Why Linearity Doesn't Work for IS-department-type Software Development  Reasons Why Linearity Doesn't Work for IS-department-type Software Development

2. Scott Ambler, abstracted from, 2002
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page