Thanks for your question. I will preface my answer by saying that my response will be what I do in practice and may not map to a PMBOK answer on a test but is definitely true to the principles of PMBOK.

Yes, we need to manage to project scope. Depending on the organization you are working in, this will mean a varying amount of stakeholder buy-in, documentation and sign-off. For this answer, I will go through a fairly textbook example of how I would get through the requirements phase of a software development project.

First, with the stakeholders I would write a scope statement. The scope statement would include not only a statement of project scope, but also define stakeholders (project decision makers), customers (recipients of the end product) and potentially some budgetary and timeline requirements.

The scope statement for a software project with be a high-level (and this is the key) of what is being delivered. For your software project it will be a paragraph or two at most stating what is being requested. For example, it could be as high-level as “Deliver a set of enhancements to the existing Employee Database and GUI to add additional career information, job categories and resume data. Reports will be added to be run on demand to query this information.”

Ok – so that’s very high-level and somewhat shorter than what I would put in a scope statement – but give you an idea. But it does define the basic parameters of what you are agreeing to. At this point I would get sign-off from stakeholders that we agree that we are working only on the Employee Database and only in the area of new career information.

At this point, I would work with my team and we would only offer a very high level effort or timeline estimate – not a commitment but an estimate. As you know, estimates at this stage have a variance of +/- 100%. But I should be able to give a good estimate f how long requirements will take – which will be the next checkpoint for the stakeholders.

Next, I would move into the requirements. So yes, in my opinion, in software requirements are a subcomponent of the Scope. And yes, you should use your signed-off scope statement as a way to stay in the boundaries of what you should be writing requirements on. Any requests outside the scope should put on a separate request list and not included. The requirements phase is where you will define every detail, following SMART requirements to define exactly what you will deliver.

Once you believe you have identified complete requirements you would again get sign-off from customers and stakeholders. With the requirements in hand, you work with your team to better refine your effort estimate (non accurate +/- 75%). Based on your estimate, your stakeholders may want to adjust the scope. (i.e. if the schedule proposed is too long, they may narrow the scope or vice versa.)

Any time a customer or stakeholder requests requirements that are outside your scope statement – this is considered scope creep as they are potentially increasing the amount of work your team needs to complete to accomplish the goals. The benefit of getting a formal sign-off on your documents is that you can refer back to these to keep everyone on track.

In the event that the stakeholders or customers want to increase the requirements scope then you would re-open the scope statement, revise it and get sign-off again. This may seem like a tedious process but it helps everyone understand the impacts they are having on the project and opens the discussion for why you may need to change the proposed schedule.

If you don’t manage these events carefully customers don’t recognize that what they are asking for are scope creep and then they perceive the increase in the time estimate as the project team’s inability to plan a project. A miscommunication that is so prevalent on projects. Project Management is all about communication.

I hope this answers your question. If not, I hope to hear back from you and we can continue this discussion

I’m not going to comment anything. But, I have questions that need your help to aswer or explain it. According to PMBOK, we need to manage the project scope stated for the project. In any projects such as software project, we also need to manage the software project requirements. My question are:
1. What are the relationships and differences between scope and requirement for software projects?
2. Is requirement a subcomponent in scope management? Are we controlling the requirements based on the scope stated earlier?

Thank you.
Shikin.

I completely agree with you. The triple constraint doesn’t represent nearly all that is important in measuring a project. In my opinion, the triple constraint is best used as a communication and negotiation tool with your stakeholders. If provides a framework to explain how things work and what needs to be changed. But a skilled project manager uses many more tools during the process of executing a project that you have pointed out are not contained in the triple constraint.

There is not a single picture, model, or scenario that describes all of project management. It is a complex web of managing many different aspects including the ones you have mentioned above. I do think the first two you mention are inherently captured in the triple constraint and the savvy project manager will bring them to the forefront.

Expert Resource Availability: true this is technically a subset of Budget. But as we both know, warm bodies does not equal a successful project. Extra testers do not make up for a shortage of developers. So what I do when I have a new set of stakeholders for a project I define what the acceptable parameters. Resources are not all equal and less skilled or shortage of resources will increase time and likely reduce quality.

Quality: I agree with you here as well and a point that I failed to bring up in the article is that if one aspect of your triangle changes and you fail to adjust the other two in response you will face quality issues.

Risks: once of my personal favorite components, although I feel it is a separate discipline concept from the triple constraint in the PM Toolkit is risk management. To me it is not something that defines the project (which the triple constraint heps to do) but instead it is something that needs to be actively managed throughout the project. For all large project I always maintain a top 5 Risks and Issues list that stakeholders are aware of at all times (obviously were are managing a larger total list of risks and issues in the background. Definitely a future topic.

Thanks for the dialogue,

Jessica

I’ve seen The Triple Constraint in various forms over the years but in my opinion it hides three VERY important constraints on a project:

1. Expert resource availability

Although The Triple Constraint includes resources under costs, it does not focus on the availability of those resources. This is especially critical where there are only a small number of resources available with the specific expertise required and there are multiple projects fighting for those experts.

2. Quality

Once again The Triple Constraint loosely includes quality under scope but this defocusses this constraint and leads to perception such as “its ok if we just add this one extra feature, we can steal some time from testing at the end of the project.”

3. Risks

Risks are not included in any of the categories under The Triple Constraint but can have the biggest impact on the outcome of a project. Without early identification of potential risks and pro-active management of those risks the project is likely to fail.

Cheers,

Jessica