Project Management

To Tailor or Not to Tailor: A Foregone Conclusion?

From the The Critical Path Blog
by , ,
Welcome to The Critical Path--the home for community happenings and events on! This is where you'll find community news, updates, upcoming events, featured member posts and more. We'll also be showcasing hot topics in the project management arena and bringing you interviews with industry experts. The Critical Path is our primary way of getting news out to members, so be sure to check back for updates!

About this Blog


View Posts By:

Marjorie Anderson
Kimberly Whitby
Laura Schofield

Past Contributers:

Carrie Dunn
Danielle Ritter
Kenneth A. Asbury
Craig Dalrymple
Rebecca Braglio
Kristin Jones

Recent Posts

Mighty Fight: The Importance of Stakeholders in Achieving Project Outcomes

Changes Coming to the Online Community!

Apply Now for a PMI Sponsored Research Grant

Project Teams—The Whole is Greater than the Parts

4 Ways to Earn PDUs—and Reach Your 2020 Career Goals

Categories: news, PMI, standards

by: Klaus Nielsen, PMBOK® Guide-Seventh Edition Development Team member

Did you know that many organizations have unsuccessfully tried to implement an off-the-shelf, or ready-made, project management methodology and found that it was unsuitable for their projects, their organization, and their level of organizational project management maturity?

This often results in a lot of money, time and effort spent with little return and a decrease in staff morale. The one-size-fits-all approach is not working, because no two projects are the same. Different people, clients, vendors, technologies, cultures, approaches, sizes and such require extensive tailoring.

Designing the delivery approach based on the context of the project, its objectives, stakeholders, and the environment is much more difficult than it may sound. Designing the delivery approach requires tailoring. We use tailoring to our project management methodology with the hope of buy-in from team members.  In some cases, a tailored approach produces a more customer-oriented focus, centers on best-for-project approach, and reflects a more efficient use of project resources.  It also helps to ensure that when the team agrees to use specific processes, tools, or ceremonies, everyone is aligned, and use is consistent.

But who has not experienced the damage from tailoring not done correctly? I have! It’s when project team members are not using the methodology, independently modifying the methodology, or following the process for the sake of the process.

When we tailor, we have a wide range of options. I tend to look at the processes and see whether it would work or not.  Often, I have been faced with too many processes of little value. In some cases, inputs, tools, and techniques may be omitted or changed to make them work within a specific context. Also, when tailoring I examine the level of documentation required, as it’s often a great chunk of work.  I want to make sure all project artefacts, documents, and plans provide value — not just documentation for the sake of documentation. Thinking back, if you had to apply everything the same way to all your projects for the last 20 years, that would be a nightmare. Firstly, I rarely do the same kind of projects the same way twice. Secondarily, if I had to do it all over, I would make a lot of changes (hopeful that I have learned something along the way). Think of tailoring as your opportunity to apply lessons learned.

I think it’s difficult to talk about tailoring without touching upon efficiency and effectiveness. Now it becomes slightly trickier. I don’t see one without the other. I know some of you may have concerns about the connotations of these terms, so let me try to explain my view.

Effectiveness talks to providing our customers with value through product delivery and producing the intended or expected result. It is also associated with the results from the actions of the team members and the project manager.

On the other hand, efficiency talks to how we are performing or functioning in the best possible manner with the least waste of time and effort. It is also associated with how things are done.

Who has not heard the following statement: “The fundamental reason why projects are late is because of inefficient use of resources. My job as a project leader is to move our expertise around to tackle as much work as possible, and to do so seamlessly?” In this case, efficiency means getting more work done with the least loss of time, which is done by maximizing utilization. In this case, efficient IS effective. In my native language of Danish, we use the same term for these two concepts.

For others, efficiency is a poison. For them it also means maximizing utilization, which requires that we overcommit and confuse our staff, leaving them no slack to breathe or innovate. To them, efficient is the OPPOSITE of effective. However, that was not the intention.

Just to wrap it up: Design the delivery approach based on the context of the project, its objectives, stakeholders, and the environment. Maximize value, manage costs, develop flow and enhance speed by utilizing just enough process. I think there might be a principle or two in there.

Posted by Marjorie Anderson on: October 01, 2019 02:25 PM | Permalink

Comments (13)

Please login or join to subscribe to this item
I agree with you in tailoring aspect of project management. Even for similar outcome of projects, two project can't be considered similar considering its project environment. Hence it is very important to tailor our approach in context of each project for successful outcome.
Thank you for highlighting this aspect very nicely!!

Very interesting., thanks for sharing

Good considerations. Every project is different and special, and need adequate reajustments.

Thanks for sharing Marjorie, every project needs a degree of tailoring and tweaking…..

The problem with process driven project management, even when tailored, is that we forget the original purpose of the process resulting in the process becoming the be-all and end-all. In my experience the fundamental reason for project management is two-fold; manage risk, and enhance rewards (benefits). Processes are put in place to achieve these objectives and if a process does not mitigate risk or enhance project benefits it should be modified or even dropped and replaced. The first task for a project team is to undertake a risk/benefit analysis followed by developing processes to respond. This does not mean start from scratch, it means apply your knowledge, experience and lessons learned to proven project management process to the project at hand.
I find there are three schools of thought out there in project management land: 1) religiously follow established processes and manipulate the project to fit, 2) throw all processes away and start with a new slate - essentially re-invent the wheel, and 3) adopt a 'new' commercial process (because the last project failed somewhat) and manipulate the project to fit. I prefer a fourth, risk/benefit driven project management modifying available processes to fit the project.

Thank you!!! The article makes some Great Points

Each project is unique , so tayloring makes always sense and may help saving resources and make a more efficient plan.

An important value proposition of PMI's Disciplined Agile (DA) toolkit is that it shows you how to tailor your process, not just your project management approach BTW. DA describes options, and the tradeoffs associated with them, so that you can make better process decisions. You can do this via a technique called Guided Continuous Improvement (GCI), which is described at .

I'm blogging about DA here on this site, so keep your eye out!

This used to be true. The FLEX System however, is designed to be tailored for the organization where it is to be used. We're currently integrating this in with Disciplined Agile to create a framework which has several pre-defined SDLCs which are straightforward to customize.

The challenge with most frameworks is that they've not been organized around the value stream so plugging and playing practices is difficult. If you're interested, follow my blog.

Here's a link to how FLEX does it.
Does your approach create an organizational operating system?

Exactly. With DA and FLEX you can put yourself in a position to start with something that meets your needs that can then be easily evolved over time as you learn and as your situation evolves.

PMI is bringing a real game changer to market.

To be able to implement tailoring it is necessary to know all the processes of project management.
Does the Project Manager have the power and authority to tailor processes to the specific pre-project it will manage?
As Project Managers We have to keep in mind the "Organizational Process Assets" and the "Company Environmental Factors"

Actually, just knowing the processes of project management isn't sufficient, although it's a very good start. If you focus on one aspect of your process (project management, architecture, security, and more) then you run the risk of local optimization. What you tailor may be great for the PMs but hamper the architects and the overall workflow that you're supporting.

When you read various "books of knowledge" you see that individually they're generally good stuff. But when you start trying to combine them you discover that they contradict one another (and often they're internally contradicting, but that's another issue). The problem is that at best they're locally optimized for whatever topic they purport to be a BoK for.

Please Login/Register to leave a comment.


"I'd rather be a failure at something I love than a success at something I hate."

- George Burns