The Standard Project Methodology: Is it Still Relevant?

Andy Jordan - September 19, 2016

A few years ago, there was no debate about whether a standard project methodology was a good thing. Organizations worked to develop and implement a single project approach across all areas where projects were carried out, and they may well have conducted process audits to ensure the process was being applied consistently. There may have been recognition that smaller projects didn’t require the rigors of the full methodology, but that generally resulted in a “light” version of the same process framework that allowed for certain elements to be simplified or dropped on smaller initiatives.

Today’s project delivery environment is more complex than ever—more projects, more complex projects and (critically) more varied projects than ever before. Does this environment still lend itself to a single methodology? And if not, what should an organization’s approach be?

The fundamentals haven’t changed
The reasons for creating a standard approach have always been good ones. The more consistent an organization is in how it delivers its projects, the more familiar project teams will be with it and the more focus can go to the work being completed. Consistency also results in more accurate estimates, and of course methodologies are developed to minimize risk, maximize efficiency, etc. If an organization moves away from a standard, it risks damaging performance against any or all of those metrics—it may well be consciously building inefficiency into the process.

However, the arguments against a standard approach are also just as true today as they have always been, perhaps more so. Standard methodologies restrict flexibility for project managers and force a “one-size-fits-all” mentality onto projects. That’s problematic in an environment where projects are becoming more varied and where organizations are recognizing that different projects may need to be handled differently depending on their purpose and contribution.

There is also increasing recognition of the importance of matching the right project manager with the right project, aligning not just style and personality but also the right combination of project and business skills. An inflexible approach reduces the effectiveness of that alignment by restricting creativity and innovation.

But project approaches have changed!
For many organizations, the biggest argument against a single project approach is the growth of agile. Any organization that delivers projects using both agile and waterfall approaches must by definition have at least two methodologies. Agile disrupts the often prescriptive approach to methodology in many organizations, and by its nature it encourages flexibility and self-organization over a rigid set of processes.

This is not only a significant change within agile projects, it has a knock on effect for traditional projects and for the enterprise as a whole. When successful outcomes are observed without rigid frameworks, the need for those frameworks is questioned.

When that is combined with the increasing awareness that different projects benefit from different approaches (what works well for an internal IT initiative may not be appropriate for an enterprise-wide transformation project, for example), the value of a single methodology is significantly undermined. The challenge comes from what to replace it with—simply creating multiple standards is not only confusing, it’s a less-than-ideal compromise. Instead, organizations should be looking at process frameworks rather than full methodologies for their traditional or waterfall initiatives.

Framework vs. methodology
There is a risk of causing confusion through language here, so let me try and define what I mean by a framework rather than a methodology. In a framework, an organization establishes some core criteria that must be applied to all projects, but allows for variation between those criteria. In this way, the framework provides a skeleton for how a project is managed, but everything on top of that skeleton can be varied to a greater or lesser extent.

Let’s look at a specific example to try and make it clearer. The framework may say that a project cannot complete the planning phase until the schedule is approved by all stakeholders and is baselined. That’s a reasonable expectation for a gating criterion and will be familiar to many project managers. However, it doesn’t impose any requirement on the level of detail that must be provided in the schedule, and that’s where the variation can come in. The framework may stipulate different levels of detail for the schedule depending on project size, complexity and importance, but it doesn’t have to and any such stipulations will be broad.

At a minimum, there may be a breakdown of tasks on a day-by-day basis with names assigned to them, while at a maximum it may require a full-blown project schedule with lead and lag dependencies, percentage allocation, etc. Guideline (not prescriptive) templates should be provided for several different levels and there should be rules established for review and approval of the approach—perhaps a requirement for the sponsor, customer representative and PMO to all agree to the level of detail proposed by the project manager.

This approach provides consistency in the major project elements, but still allows individual project managers the freedom to manage their initiative in the way they feel is most relevant. Governance processes and the guidelines around the use of the framework will help to eliminate any attempts to cut corners, but within the boundaries of the framework the focus is on relevant process rather than arbitrary compliance with a fixed methodology.

There may be a need to restrict the flexibility for certain types of projects—I know of organizations who insist on more rigor when two or more business areas are involved, for example. In other cases, projects may be able to be conducted using less formal methods because of other factors—a server refresh that shares many similarities with previous server refreshes won’t need as much structure as a similarly sized project in a completely new area.

It is important to combine these frameworks with recommended practices that will help PMs to be optimally effective and efficient; but to be accepted, those practices must come from the PMs themselves. Encouraging PMs to share experiences and suggestions around how to leverage the framework with each other will result in far greater improvements than mandating such changes from a PMO or similar body.

This also places accountability for ownership of the framework—and improvements to it—in the hands of the practitioners, leaving a PMO or other governance body to simply review and approve those enhancements. It’s much harder for practitioners to object to the framework if they not only have freedom to work as they please within the framework structure, but also to improve the framework itself.

For agile, the methodology or methodologies used by the organization should be appropriate without modification. The nature of them is to provide only a high-level framework, encouraging team members to work as they see best within that framework.

However, there are still two significant considerations that organizations must make with agile. The first of these is the establishment of consistent criteria for when agile should (or can) be used for project execution. While agile is ideally suited for projects involving high degrees of uncertainty and/or complexity, each organization will have restrictions around business areas, project sizes, etc., and these must be clearly communicated and consistently applied to avoid causing confusion among project delivery areas.

The second consideration is the use of a standard agile approach rather than allowing for individual variations. While this may seem counterintuitive when I talk about providing flexibility on more traditional approaches, agile is already less structured and doesn’t need the same degree of additional flexibility. Until an organization becomes comfortable and experienced with agile, I recommend they stick to a “textbook” approach.

Once they have reached a level of comfort and maturity that allows them to understand the shortcomings of the approach (as opposed to their challenges in applying the approach), the various agile areas can collaborate on any customization they wish to make to that approach. Any such customization should be made at the enterprise level and applied to all agile initiatives. If the organization wishes to create a hybrid approach that contains elements of agile and waterfall, then the traditional framework and agile approach can be combined—with each being applied to a subset of the overall project.

Conclusions
I’m not much of a process purist, so have always felt standardized approaches to project delivery bring more restrictions than benefits; but I also recognize that organizations must do everything they can to maximize their chances of project success. My concern was always that standard processes didn’t always optimize effectiveness and efficiency; rather, they created an “approach of least exposure,” eliminating outliers and moving everyone to the middle.

While that had advantages at the lower end, it is restrictive at the higher levels of performance (where we all like to think we operate). With the increasing diversity of project execution approaches that are required to support the ever-expanding types of initiatives being undertaken in organizations today, a single standard approach cannot be successful—the compromises are simply too great. Instead, organizations must look for ways to allow variations on a framework that balance “boundaries” to those variations with the creation of an environment where PMs are encouraged to innovate.

In the next few years, more and more organizations will be forced to move away from a single standard methodology—not just because of the increasing expansion of agile, but because the nature and variety of projects will dictate different approaches within the same overall framework. Every year, we are expected to become more efficient and more effective, and that requires a flexible approach within an evolving framework. Excess rigidity will be just as certain to fail as the absence of any consistent approach.

---

Comments (35)