Blog

Content

• The Challenge
• The Goal
• Considerations
• Next Steps

The Challenge

There are a number of project methodologies. And before AI came along the latest hype was to be Agile. However, multiple studies show that no one methodology is best for all types of projects nor necessarily for the project environments in which they run.₁

Many managers have attempted to check the checkbox that they have implemented their methodology. However, for some this accomplishment did not significantly improve their project environment, or may have even made it worse.

I find it interesting in project methodology decisions that a manager gets sold on a specific methodology because of some external factor. The manager may be overlooking their own project environment in which the methodology needs to be implemented to be successful.

Some areas you may be experiencing methodology pains could include the following.

• You may have all or some clients who want a specific methodology that does not match your preferred implementation method.
• You may have a mix of project types that may not all be a good match for the same project methodology.
• You may see project practitioners and teams not engaged in your methodology, and just going through the motions and keeping their heads down working.
• You may see a mismatch of what is supposed to be a light methodology, but the staff asks for fewer meetings.
• You may see that those implementing the methodology and management are not in sync, with some obvious tensions and finger pointing.

The Goal

How do you get to a project methodology or tool box that suits your project environment and organizational goals?

Step One, zero in on your priority goal. This isn’t a methodology goal. This is your organizational goal.

Your methodology, the how, is what you figure out after you have your organization goals in place. The organizational goals should be the driver for how you reach these goals.

In other words know your priority, AND keep an open mind in finding a holistic “how” solution that will accomplish what will work for your organization. To be blunt, I would advise against making a specific project methodology as your priority goal. First get a good assessment to see how that or an appropriate method matches up.

Considerations

If you are selecting a methodology or tool box for your organization or group I would encourage you to look at the rationale behind each methodology and where each is used and what they are designed to accomplish.

As one example of this, the Agile Manifesto₂ and its Twelve Principles₃ clearly outline some worthwhile values and principles that are appealing and needed for some types of projects. The focus includes customers and teams. It does not specifically include “management.” Management is not included other than the expectation to support the agile method and provide feedback and direction at specified times. It comes up a bit short for some managers who need/want more than burn down charts and run rates to plan for resources, budgets, and business commitments of scope and timeline. These shortfalls across varied methodologies can be true even in organizations that have multiple levels of management that all give at least lip service to the chosen method.

Whether agile or some other methodology, each methodology has its focus and purpose. And they are not all the same. Each has its strengths and weaknesses.

There are many methodologies. And within each you can find those who try to implement them prescriptively or based on their principles. This is another factor to consider in how your methodology should be implemented.

If you do select and prioritize the implementation of a specific project methodology, a word of caution is applicable here. Consider your goal from the Goal section above. And find a methodology that aligns to your organizational or group outcome goals. Without a big picture of how it will fit in your larger project environment, you may see some success, but will likely have some gaps and mismatches.

If you come to a decision point for a specific project methodology, please consider how you reached that decision. A few possibilities that may have led you to your decision could have included the following.

• Perhaps others in other companies you admire have implemented a methodology successfully.
• Or you have done your research and seen the positive attributes of a methodology, and you want those qualities in your organization or group.
• Or you need a checkbox checked that you have done your part in implementing a viable methodology.
• Many claim the methodology is best practice for your industry.

I invite you to vet your thinking about methodology. While it is not the entire makeup of your project environment, this is a significant part of it.

Many will claim “best practice” is synonymous with their methodology. I see best practice as one possible guide that may or may not apply well in your organization. Dr. Bradley Wilson points out in his article that Best Practice may not always be Best for your organization.₄ He is not alone in his observations.

In multiple organizations the decision to bring in a specific methodology coach, or introduce any new methodology has not come from an unbiased big picture assessment of “your” environment.

If you get it wrong this can cause a downward spiral in forcing an implementation of a method without considering the people, the stakeholders, and the rest of the environment. And in some cases the method may not really reflect what management’s real need or desire is. These mismatches can cause strained relations between purists in the methodology and management needs. The processes can become meaningless, broken, and very visibly cause more hassle than productivity.

Doesn’t the decision for the methods and tools you use deserve more than an attempted lift and shift from another organization… that in some way(s) is different than yours?

Just as the puzzle pieces in the image attached to this article show, the methodology is not your whole project environment. There are other puzzle pieces that you put there, knowingly or not. These either make your environment match and work well together, or result in a mismatched patchwork that creates stress, strain, poor outcomes, over budget and late project deliverables, and excessive waste.

Next Steps

Look at what your priority is… that is the end goal of what your organization provides. What is your value stream? There is usually more than one way to accomplish your end goals. Setting a goal of implementing a methodology (the how) without first matching it to your priority and the realities of your project environment can result in… a MESS.

Please reference the Project Methodologies article for Project Practitioners and consider not only the methods, but your environment, and AI tool and process implementations. It will add a bit more context worth considering for your environment that churns out the deliverables from your projects.

The Project Realm works with people in new and existing environments, and makes assessments both inside and outside of your project scope to help tune your environment across twelve areas of alignment and impact that match with your organization goals and norms. When you are ready to improve your project environment please contact The Project Realm.

1 Jim, Sheffield, and Lemétayer Julien. “Critical Factors – Select a Fitting Project Management Approach.” Pmi.org, 2019, www.pmi.org/learning/library/select-fitting-project-management-approach-6915.

2 Beck, Kent, et al. “Manifesto for Agile Software Development.” Agile Manifesto, Agile Alliance, 2001, agilemanifesto.org/.

3 “Principles behind the Agile Manifesto.” Agilemanifesto.org, 2001, agilemanifesto.org/principles.html.

4 Wilson, Bradley. “When Is a Best Practice Not Actually “Best” for Your Organization?” Perceptyx.com, Perceptyx, 14 Apr. 2023, blog.perceptyx.com/when-is-a-best-practice-not-actually-best-for-your-organization.