PROJECT METHODOLOGY MODELS

When organizations describe their methodology, they are implying that there has been some formal thought and standardization regarding the technical and manage- ment approach to be used by their projects. This is a general term and there can be a methodology to operate a lathe in the machine shop or to execute a particular type

of project. The term is prescriptive in nature and in the project management domain this implies something akin to a standard that is formally supported by management. In fact a methodology without this characteristic is generally worthless. A common term formally used by computer types said “the nice thing about standards is that we have so many to pick from.” Pause for a second and think about that statement. It often applies to methodologies and unfortunately raises a question about following any one of these since another is soon to follow. The PMBOK® _{Guide is in fact a high-level project}

management methodology model sponsored by PMI that has stood the test of time. In other cases, published methodologies are most often defined by industry or con- sulting organizations to fit their general class of problems, organizational culture, and other such factors. For many industry types, very robust methodologies are for sale by third parties; however, buying a commercial methodology and installing it unaltered in an organization will typically result in minimal or nil value—project management is more than a mechanical set of steps. To be successful with any methodology there is a required stakeholder buy-in and customization. A customization process helps support organizational buy-in and generally increases the odds of success. A standard model has the advantage of supplying an extensive pedagogical and documentation base to evolve from. Regardless of the evolutionary process chosen, organizations need to consider making ongoing investments in improving their standardized process methodology. The caution here is that an organization cannot just create a methodology and send out the documentation for team members to read. This must become part of the culture, as well as a formally communicated and ongoing process supported by management with input from appropriate stakeholders. Also, it has to make sense to the project teams who will use it. A project team member once described his required methodology as “feed- ing a dinosaur.” The implication was that it required a lot of feeding and did not bring added value. If that is the perception, it will be hard to sell the process. Project team members are under too much time stress to want to do something that does not appear to help them produce a desired output. This same criticism is common for project man- agement in general and educational efforts are important to show why doing activities that appear to be wasted overhead do in fact add value. There is a fine line between good project management and excessive overhead. Only enlightened professionals can judge the proper balance.

Part of the evolutionary process for a successful business process is to document past experiences (good and bad) and continually redesign them in an attempt to optimize the next iteration. Projects have both a technical process component and an intertwined management layer. The technical components are represented by the task sequence nec- essary to produce a product, while the associated management tasks add management visibility and control related to those processes.

As an organization matures their methodology usage, they will tend to add selective processes related to the various KAs represented by the PMI model. For example, this maturation process will highlight the value of formal management related to areas such as risk, communications, and quality that would have been essentially ignored previ- ously. This statement is particularly true related to risk management activities.

An earlier example illustrated a general set of activities relevant to the project life cycle. Many organizations have taken this type of view and customized a task list sur- rounding that phased approach. This model has even been given the name waterfall to describe how the various phases progress in more or less cascading serial fashion. We also described how this same phased view would generally fit many other project

Project Life Cycle Models • 65

models. Given the definition of a project, all methodologies should define a formal start- ing point (initiating) and a closing process regardless of how the internal work processes are connected. The middle of the life cycle will contain activities related to planning, execution, and control in some form. Logically, some level of initial planning is required and the execution phase represents the core product delivery activity for the project, so much of the technical work sequence would be defined there.

Monitoring and control strategies are more philosophical in nature in that there are varying opinions as to how much of this should be done; however, some form of this should be added to the basic workflow. Very few projects can exist without a formal status reporting activity. The PMBOK® _{Guide is very rigorous in this area, more so than}

most organizations follow. In addition to these broad process groupings, the concept of defined phases is fundamental to the management control process. Even in a low technology project such as a prefabricated house construction project there is a need for some defined phase management review. In this example, the phases may need to be established simply to confirm that the foundation meets specifications, or that the wir- ing and plumbing are installed properly before allowing the process to move forward. For more complex projects, the phase reviews become much more rigorous and include the complete gamut of project status parameters. For a more complex class of project, the phase review often is dealing with the decision to kill the project, rather than just being sure that the previous step was done properly. Note in these two diverse examples, the management role is to properly approve what needs to be done for successful com- pletion and then monitor that definition and status through the life cycle. In the house construction example, the primary issue was to execute the technical sequence using industry standards, while in the high-technology effort the control focus would be for both technical and management concern. Thus, we recognize that a single standard methodology would not fit both of these project models, even though the general life cycle sequence for them is comparable.

As indicated earlier, there is broad strategic organizational value in defining a stan- dard methodology. The most obvious value is the savings related to having to reinvent a basic technical and management sequence for each project. It is much easier to tweak a standard tested model and use most of it than to think through a complete project plan each time. The standard model will have been tested for validity and the workforce should be knowledgeable regarding its processes and vocabulary. Also, management will have approved the related control process and structure aspects. Personal experi- ence suggests that this form of project execution can provide significant productivity benefits. All underlying rationale related to the role of methodology standardization is important to the PM and he needs to understand its value and limitations. The chal- lenge is to motivate the project team and organization to follow something akin to a standardized approach. If the organization views the PM to be a maverick with wild and nonproductive ideas, he will be judged as a nonteam player. This is not the attribute that one wants to exhibit in a PM role. Realize that this is not an engineering mechanics task, but involves the additional complexities related to the associated organizational and human culture side.