3

Let's say a vendor is a software development company. It is developing a software product for a customer. But, during the development of the product, it discovers technical problems that were hard to foresee (and add to estimations) at the beginning of the project and these technical problems make it impossible to implement the product on the agreed date (the agreed end date of the project).

Is this the situation where the vendor can use the change management process to increase the scope and shift the delivery date to a later date?

Improve this question

3 Answers 3

Reset to default
3

It depends on the operating model for the piece of work (and maybe the contract as well). Of course you must expect unforeseen problems to be identified during testing - if there aren't any then surely you aren't testing hard enough! If you are running the project from a backlog then those defects can go onto the backlog and get prioritised along with everything else.

The term change management normally refers to changes in functionality, not defect fixes. Sometimes it may be a matter of opinion as to whether something is a change or a fix but that distinction is usually less important than the priority attached to the work. I would not recommend having a contract or operating model that attaches any great significance to whether something is a change or a fix.

Improve this answer
3
  • What about something like "We were planning to implement this with SQL, but whoops! It looks like SQL can't handle this use-case, so we have to implement it with JSON instead and that will add X weeks to the project."
    – nick012000
    Oct 10, 2020 at 5:08
  • @nick012000 sounds like a case of re-estimating something rather than a change or defect.
    – nvogel
    Oct 10, 2020 at 8:54
  • I think it depends on how SQL became part of the SOW and how it reads in the SOW. Was it your solution? Was it agreed upon solution between both parties? Was it a requirement by the customer?
    – David Espina
    Oct 13, 2020 at 19:30
4

I'm not sure I understand. It almost sounds like the example is using change management to avoid contractual consequences, which is not the intent.

The job of the project manager is to estimate and communicate project completion date to the sponsor and relevant stakeholders. In your example, an issue caused the delivery date of a key component to slip.

Change management will help all the stakeholders to understand the impact of this slippage on their tasks. It will help to replan the project and revise the estimated completion timeline and costs.

vendor can use the change management process to increase the scope and shift the delivery date to a later date?

This seems to imply that the vendor is using change management against the rest of the project team. It might imply that the vendor is using change management as a tactic in contract management, which is quite contrary to the intent.

I'm not sure where in the example the scope has changed - the slipped delivery date for the vendor's task affects the schedule, but there is nothing in the example that would affect the scope of the project.

The precise terms of the contract with the vendor will determine which party needs to accept the consequences. Contracts are written to price risk to one of the parties; in this case, the risk (Given that software development requires some research, if the development estimate is flawed, then delivery will be delayed.) transformed into an issue. The terms of the contract will determine whether the vendor or the purchaser has to bear the consequences of that issue.

Improve this answer
4

A change process changes baseline values for scope, time, and cost, and for legitimate reasons. A variance on schedule is not a legitimate reason for a baseline change, generally speaking. It could be if the reasons for those variances were for external obstacles such as a hurricane that caused a stop work, or perhaps a legal issue. Being late because work is taking longer than expected or because you're coping with a ton of issues is sort of a normal set of causes for being late...this just makes you late.

If you could make a case that, while trying to resolve these issues you're facing, your customer is not performing their part, maybe to participate in problem solving sessions or approving timely solution proposals, then you might be able to argue a schedule change secondary to non compliance. I wouldn't word it that way but that is essentially the cause. There are a lot of variables involved that drive schedule variances so if you can identify one that is caused by another stakeholder group, maybe you can make a change case. I have worked for IT sellers and they attempt this all the time. In my experience, we lose that argument probably nine out of 10 times.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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