Working with Project Managers to Juggle the Triple Constraint

The relationship between Business Analysts and Project Managers is often described as being built on a foundation of “healthy tension”.  There is an assumption that PMs focus on project delivery, deadlines and resources – and it will often be considered desirable for a PM to challenge analysis estimates and cut schedules.

One concept that links the BA and PM profession is the triple constraint. This can be an exceptionally useful concept to keep in mind when discussing BA effort estimates and delivery dates.  It can act as a common language in which to discuss resourcing or scheduling issues, and can help us to respond to any challenges our PM colleagues throw at us!

There are many ways of expressing the triple constraint, but essentially it shows a balance between project budget, schedule, scope and quality. It is often drawn as a triangle:

The triple constraint of project management

The triple constraint of project management

The key thing to note from this diagram is that if any one of these dimensions change, it will have an impact on at least one other.  For example, if resource is cut (or is inadequate to start with) then scope, schedule or quality will need to be adjusted to compensate.

I’m sure we’ve all worked on projects where one or more of these dimensions is immovable.  This causes an issue when there is insufficient resource or time.  All too often there is a fixed launch date for a product, whilst also having a finite (and insufficient) amount of BA resource available.  In these cases we have to work creatively with our PM colleagues to find a way of delivering the projects whilst also meeting the required constraints.

The key is to know which constraints can’t move. Whenever this situation occurs, the first question I ask the project manager is how much flexibility we have, and I work with them to establish which dimension is constrained.  Once this is clear, it is possible to start brainstorming potential solutions.  Here are some questions or considerations that can be helpful:

  • Time: Can the analysis period be extended?
  • Resource: Is it possible to employ more resources to get the job done quicker?  Beware! This won’t work on all projects, and there certainly isn’t a linear relationship between resource and productivity.  The more resource employed, the greater the co-ordination overhead.  In fact, in some cases, employing more resource might be such a significant overhead that it has little or no impact on the timescale.
  • Scope: Is it possible to reduce the scope of the analysis (or the scope of the project) in order to meet the deadline?  This could involve phasing of the project, phasing of the analysis, or even producing less documentation.
  • Quality: Could it be acceptable to reduce the quality of the analysis, for example by making some assumptions? This can be dangerous, and it’s essential that this is done in a pragmatic and calculated way, to ensure that the risks are understood and managed.  In many cases it is just creating a problem for the future, and on some projects quality may not be negotiable at all.
  • For all constraints: Is there another way of approaching the problem or conducting the analysis?

By varying any dimension, the risks on the projects are likely to change.  For example, if scope is changed there may be a risk that the solution won’t meet all stakeholder requirements.   It’s important to articulate these risks up front and ensure the correct mitigating action is taken.

Beware of any project managers who tell you that none of the dimensions can move.  Quality tends to be the dimension that suffers by default.  If 3 BAs are forced to do the work of 10 BAs, with no flexibility on any of the other dimensions, then they are likely to have been extremely rushed.  It is always better to make a conscious decision over which dimension to squeeze, and ensure the project manager or project sponsor makes an informed decision based on the associated risks.

In summary, whilst planning and scheduling are a Project Manager’s responsibility, it is useful for a BA to have a firm working knowledge of the triple constraint.  This helps us to work in partnership by asking the right questions, in the same language as our PM colleagues.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Celal Murat PARLAK says

    Hey people,

    I wished to comment on the changing the PM Triangle’s focus point to quality in spite of scope.

    I strongly disagree the change of placement since it is the “scope” a PM’s deciding factor. The thing to decide here is the scope since it pretty much concludes quality we accomplish at the end. And to achieve this quality, how much resource and time we will administrate.

    Despite to this, as a BA we may be focusing at the deliverables. And it is pretty much focusing on the quality yet; we can’t be ignorant about the requirements of the IT management, can we?

    I am a junior BA but i wished to contribute with my opinion.
    Best regards,


  2. William,

    On second thoughts, I *don’t* think putting “Resource” in the middle works. This would imply if you reduce time, you need less resource…. which wouldn’t normally be true!

    Having revisited this, I think that the most accurate representation would be to have “quality” in the middle. In many ways, “quality” is the attribute that suffers by default. If one reduces time without adjusting scope or resource, then it’s likely that work will be rushed… and quality will suffer.

    Thanks again for your comment, it has made me re-examine my previous thinking. That is why I enjoy posting articles here so much, I always get such valuable feedback!


  3. Hi William,

    That’s an interesting question, and has prompted me to re-visit my original diagram.

    I think putting resource in the centre of the diagram works. You would then have three sides:


    With “Resource” in the middle, the diagram would imply that if scope was reduced, if quality was reduced, or is time was reduced, that less resource would (should) be required. This seems logically true.

    Having re-visited the diagram above, I think that putting either Resource or Quality in the middle of the triangle would be a a more accurate representation than my original diagram.

    Thank you very much for your comment, it has prompted me to think again about my article!


  4. William Sam says

    Mr Reed
    its just a question, what if the resource is placed in the center of the triangle then and Quality/scope to the line can u still interpret on that modified Scope triangle or not? its based on a question that was given to me to answer

  5. Mr Medici, thank you very much for taking the time to comment and to share your strongly held views on this topic. Your valuable comments have certainly made me think!

    I agree with you that there are definite limitations to this model. In many ways, this model is a representation of reality – and it’s important not to get that confused with reality itself. To quote a cliché “The map is not the terrain”.

    So, for example, there is unlikely to be a direct linear relationship between any of the dimensions shown on the triangle. A 10% reduction in scope won’t necessarily mean a 10% reduction in budget or time. However, the model is not meant to be interpreted this way. It is a model which shows potential areas of impact, and certainly the mathematics of the triangle will not represent the complex interactions and interdependencies on an individual bespoke project.

    The reason I think it’s useful to show quality in the middle, is that it is the attribute that is often forgotten, and it tends to suffer by default. The reason I think having it explicitly shown on the model is that it prompts conversations.

    So, in summary, I agree with your comments that the model will not capture the precise complexities of a project. But I believe that doesn’t detract from its usefulness. It allows the project team to start a conversation – with a shared language – around potential trade-offs that can be made.

    Thanks again for your comments – they are extremely valuable and valid, and expose how many different viewpoints there are within the profession.


  6. David Medici says

    Mr. Reed, your Scope Triangle is wrong. While it may sound picayune I feel I cannot state it too strongly–especially as I find it so often misunderstood–namely, Scope is defined by the Time, Resources and Features/Functionality to be produced. Quality is not, repeat NOT, a bound on Scope. Quality is a non-functional requirement of the Features/Functionality. Quality is a measurable attribute of the produced product.

    Some claim the Features/Functionality, or product, is inside the triangle. No. The triangle is meant to convey the relationship between the sides, not the area within. Understanding the correct tripartite nature of Scope is essential. With the correct understanding in place we can visualize how two sides of the triangle must respond when one side is varied. Add more Features/Functionality and either Resources must be increased to keep Time constant, or Time must increase to permit the operation of the unvaried Resources, or both Time and Resources must vary each to a smaller degree for the production of the expanded Features/Functionality. There is, we could say, a trigonometric relationship between the three components of Scope.

  7. Hi Claire,

    Thanks very much for your comment. I completely agree – a strong relationship between the BA and the PM is incredibly beneficial. Having this kind of rapport means that information can flow freely, both formally (through status reports, e-mails etc) but also informally (over coffee, at the water cooler). Sometimes the informal communication is even more valuable, and often more accurate, than the formal communication!

    Thanks again for your input Claire, much appreciated.


  8. Claire Connor says

    Hi Adrian

    Love the discussion, the point I would like to highlight around the amount of documentation reminds us that we should be discussing the approach very early with the PM in order to both understand what is involved early on and grow in that understanding together. You then both not only agree approach but what is achievable in the timeframe and the best way to capture it to suit the project and stakeholders.
    I’ve always believed that the BA and PM are two sides to the coin and the project won’t be successful unless the partnership works. These discussions early on mean that the bond between the two starts as you both grow the knowledge of each other, both personally and professionally.
    This has always worked well for me in the past.

  9. Hi Dave,

    Thanks for the reply. You raise a very valuable point with regards to the amount of documentation produced.

    My personal view is that there’s a fine balance here, and the key is to produce “just enough” documentation to support the project’s objectives. In determining how much is “enough”, the BA needs to take into account the project team, the business stakeholders, the developers, the project delivery technique etc. There are so many organisational and project variables which affect how much documentation is “enough” and how much is “too much”!

    Changing the amount of documentation produced could well introduce new (or different) risks, and it’s always worth ensuring the project team and PM are comfortable with these.

    I also agree with your point about quality. The triple constraint is a great way of demonstrating the potential impact on quality when speaking to stakeholders.

    Thanks again for your reply, I hope you enjoyed the article.

    Take care,


  10. Hi Mike,

    Many thanks for your reply. Using the “triple constraint” diagram to visually highlight problems with an in-flight project is a really good idea – I had never thought of using it that way before! It makes so much sense, by visually highlighting the problem area, I can imagine it really helps to focus conversation on getting a resolution.

    Thanks for sharing this technique – I’ll definitely be using this!


  11. Dave Schrenk says

    I sometimes respond by adjusting my analysis technique and, as you briefly mentioned, producing less documentation than I would under ideal circumstances. This usually means developing only high-level use cases or other models and only documenting the details through textual requirements. Of course, this approach can impact quality since it increases the risk that a detailed requirement is overlooked or those that are documented may be incomplete or inaccurate. I use the triple constraint concept to explain the potential impact on quality to the PM and, oftentimes, the stakeholders.

  12. mike Lachapelle says


    I have used a variant of this model a number of times when presenting to senior or executive management on the status of a project. What I have done is put the three resource components as the end points of the triangle and the scope s a circle in the centre of the triangle. To emphasize the current state of the project going wrong, I adjust the text size and bold where shift has happened with the resource factors. If the scope is beginning to blow out I resize the circle so it no longer fits within the triangle. It is a very effective visual, particularly when it is the only image on the page with no words – leaving the comment to me to explain.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.