Let's consider a software development project. Let's further suppose that in the middle of the project it becomes clear that it can't be completed on time due to an extra work that couldn't be predicted at the beginning.

What do we do? Which PMBoK process do we use? Does it necessarily entail penalty for a development company?

  • 1
    Manage expectations. What does your risk management plan say? What does your communications plan say? You probably need to analyze the risk, determine potential mitigations and revise your estimates of project schedule, scope and cost, and do configuration management and stakeholder management. The point of writing all those plans is so that when it becomes clear that.... X, you've already planned the outcome.
    – MCW
    Sep 16, 2020 at 17:42
  • 2
    Regarding "Does it necessarily entail penalty for a development company?" - depends on the details in your contract.
    – Sarov
    Sep 16, 2020 at 17:52
  • @Sarov As a manager in a software development compnay, how do I learn what details I should include in a contract so that it doesn't entail too much penalty in such case?
    – Daniel
    Sep 17, 2020 at 15:08

5 Answers 5


Within PMBoK, you are using the processes under the Plan, Execute, and Monitor & Control process groups and within all 10 knowledge areas.

When you are seeing signals of an unfavorable schedule variance, you analyze root cause: scope creep, unidentified necessary work, unfavorable resource variance, optimistic planning value for time, etc. Then, you determine if you can do anything about it, such as bringing in additional labor, changing your approach to the work, etc. Then, you communicate the identified variance, the cause, and your plan to relevant stakeholders. Some of the unplanned work might be contractually out of scope, which means you might be able to pursue a change. With an approved change, you get a new schedule which means you are no longer late. You need to investigate that, too.

Penalties for unfavorable variances will be documented in your contract. If no such penalty is there, then you will not suffer any penalties except for maybe a bruised reputation.

  • Are unforeseen technical problems (poor integration with with third party software or hardware, investigating a complex software bug, etc) out of scope and can be considered as a change? If not, then how do I secure my company revenue against penalties caused by such problems?
    – Daniel
    Sep 17, 2020 at 15:16
  • @Daniel, I saw you asked a question similar to this comment. I answered there. Sep 17, 2020 at 17:03

The PMBOK's full name is "Guide to the Project Management Body of Knowledge". It isn't designed to tell you what to do, but it is a way of organizing the breadth of knowledge that is likely to be useful and relevant to someone working in the field of project management.

The most relevant process group would be the Monitoring and Controlling Process Group. These are the set of processes that are about reviewing the performance of the project and updating the plan as necessary, including monitoring and controlling work, performing change control, controlling scope, controlling schedule, monitoring risks, communicating, and managing stakeholders.

The most relevant knowledge areas would be Project Scope Management, Project Schedule Management, Project Risk Management, Project Stakeholder Management, and Project Communication Management.

What you do would be define in your project plans. There are different ways to organize planning information, but early in the effort you should have considered how you will manage scope, schedules, and risks. When the project meets thresholds, you will need to communicate with stakeholders to inform them of the health and status of the project, which would have been defined in some kind of communication or stakeholder management plan. If you had a specific contract with a client, these plans would tend to be agreed to by both parties as part of contract negotiation or project planning.


Try this:

Money is penalty enough. Whatever the penalty, it will hit you too (ROI, burnouts, etc.). Assume also that with a 50% or more chance, your side might be the reason why the project is going to be late. Like a failing marriage. The "Let's consider" is ringing another alarm bell. Let's not consider, but let's be present and specific. Also, "What do we do?" becomes a "What do I do?"...

PMBOK: Stakeholder Management


Scope creep or gold plating is not allowed when the task you are about to do is not included in scope management plan so the best thing is either to request the CCB for a change request or stakeholder communication to keep your stakeholders up to date of the scope changes on your project for possible considerations.


When I did consulting for a full-time living, I lived by Herman Holtz's (Hermann Holz ...) books on "consulting contracts." I constructed a contractual system based on task orders. The work was done by defining task orders and then completing them. And, if the "ordered task" changed, the order had to be amended, revised, or replaced. The discipline – once clients got used to it – worked extremely well, and of course it really came down to "project management."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.