Methodology

In Professional Services Organizations (PSO) methodology defines the philosophy, procedures and tools the organization practices. It is methodology together with experience applicable to a given problem that defines the value of a PSO.

A well constructed methodology will:

q Serve as proof of competence and competitive differentiator

q Decrease project risk and increase project margin

Proof of Competence / Competitive Differentiator

In most competitive sales cycles the prospective client looks to maximize the deliverable while minimizing the cost. To achieve this they look for a PSO that demonstrates conclusively it is capable of delivery, handling the obstacles along the way and is able to do so with competitive fees. The PSO that demonstrates this competence to a higher degree than its competitors is likely to win the engagement.

Methodology, in the form of a comprehensive stepwise task hierarchy, serves as demonstrable proof of competence. Each step highlights a process of identifying a potential problem and elucidates resolutions as tasks. The methodology represents a plan the prospect may follow step by step and task by task that will lead inevitably to the end goal.

Project Risk / Project Margin

It is possible to build a methodology so comprehensive that deliverable success is guaranteed. This methodology would leave no stone unturned, define every contingency and provide no opportunity for surprise. This methodology trades risk for effort and would eliminate any value the project represents to the customer.

Rather, a well constructed methodology must allow a balance of risk versus effort to achieve a defined tolerance. Methodology must therefore be scalable. Each step within the methodology would ask for intelligent analysis with the idea that the step may be omitted if it is not applicable or where the balance of risk versus effort is not consistent with overall project objectives.

Yet, a well constructed methodology is not simply a collection of tasks and steps. Project controls and interim deliverables are defined down to the content and format. Project resources do not have to reinvent previous work and may better utilize their time toward objectives. Project tools and utilities are also defined so that project resources do not have to spend time evaluating and procuring. Project procedures are defined so that behavior is consistent and repeatable. These predetermined elements together with scalability allow ommission of unnecessary work and shortening of the path to the end deliverable. 

… My Background in Methodology

In each of my Practices I drove development of methodology as fundamental to business operation. As illustration I present my experience at Alltel. While at Alltel I was part of a small team that crafted a major new methodology. Almost three dozen methodologies were in use across ALLTEL. These methodologies varied from commercial offerings to home grown to hybrid solutions. They were used in general project management, software engineering, business consulting and platform engineering. In general, except for semantics and structure, 90% of the content in these methodologies was the same.

Of the methodologies in use (except for perhaps Anderson Method/1) few enjoyed a significant following and most were only partially utilized. Even fewer contained the right mix of people, process and technology features required to make them readily deployable in the project environment. Most were either relegated to shelves or abandoned. Some of the more common difficulties included:

q Too rigid or complex to be employed

q Too static to keep up with the pace of technology change

q No vehicle for interaction or process improvement

q No allowance for optional processes or substitution

q Unable to be used for spiral, iteration or rapid time to market projects

In late 1997 we recognized the need to develop a standard project management and software engineering methodology. Both commercial offerings and in-house choices were considered. It was determined that a hybrid should be developed which supported best practices, afforded flexibility for different practice areas and could be viewed as a service differentiation for the organization. In the first quarter of 1998 we released a methodology dubbed the 5DLC for Define, Design, Develop, Debug and Deploy.

The 5DLC is composed of both project management and software engineering processes. While project management can function alone and be used in a wide variety of endeavors … the inverse is not true. Very few software-engineering projects have been successful without some project management. Therefore, this integration should not be changed, but project management processes should be annotated and delineated from software engineering processes.

The structure for the 5DLC was developed from decomposing various methodologies and then synthesizing best practices. Inputs included EDS SLC3 & PM2, Anderson Method/1, James Martin RAD, Rational Objectory, the Project Management Institute (PMI), the Software Engineering Institute (SEI) and others.