PM 1 - Week 2 - Models and Methodologies

Life Cycles

Question: Why do you think people resist following certain methodologies even when they are mandated by the organization?

The most obvious answer is this: improvements and innovation are rarely spawned from mandates and formalized methodologies. In Investigating Determinants of Software Developers’ Intentions to Follow Methodologies, Bill Hardgrave writes that "Results from a field study within a large organization indicate that developers’ intentions are directly influenced by their perceptions of usefulness, social pressure, compatibility, and organizational mandate."

In a sense, the individual becomes a product of their surroundings. This can be a most stifling environment for employees looking to exert a sense of individualism or creativity, especially if the practices needed to achieve such goals fall outside the methodology set forth by the employer. While Systems Development Life Cycles are beneficial to those involved in the sense they provide a detailed outline and map for phase creation and modification, they can be viewed as rigid and unflinching.

An SDLC calls for a series of comprehensive management controls. This means that an overseer must maintain a sense of authority and direction over every project, once again taking away from the possibility of creative or innovative thought from the individual employee. The Pros and Cons here are obvious; while the SDLC maintains a high level of organizational structure and ensures timely work flow, it lacks the innate freedom of thought and expression from which most new and revolutionary ideas and concepts are born from. This differs greatly from a set of rules and regulations for the workplace laid down by, say, Human Resources. Those guidelines are there to establish a level of conduct appropriate for the workplace, not affecting the actual work and/or product itself. The SDLC could create a sense of monotony or repetition in the workplace, a dangerous precedent to set in aggressive markets such as information technology, where staying ahead of the competition is far more valuable than keeping up with them.

As quoted in Chapter 2 (2.5, Life Cycles and Management Reviews):

"If the project, product and systems development life cycles are not integrated, the information technology cannot be kept up to date as advancements are made at a rapid pace. What is current today is obsolete tomorrow."

I would think that the fear of becoming obsolete moves many people to resist certain organizational methodologies. It becomes a type of man vs. machine argument where the vision of one can predict what a SDLC cannot. And with a dizzying array of options available in the current market, who is to say that the methodology currently being used is the correct one for that particular organization?

All of these are just some of the many reasons why people will often resist certain methodologies even when they are mandated by the organization.