Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Integration Management, Risk Management, Scope Management
You are managing a software development project, and one of the developers tells you that he added a new feature that he heard the sponsor talking about in a hallway conversation. The developer compl
You are managing a software development project, and one of the developers tells you that he added a new feature that he heard the sponsor talking about in a hallway conversation. The developer completed the work after hours, and it does add a lot of value to the solution. How should you manage this?
A. Thank the developer for his hard work and communicate this as a win in your next status report.
B. Document this as a change request and follow the Change Control process to ensure it is documented and approved.
C. As there were no costs incurred from the work and no schedule impact, you do not need to do anything.
D. Ask the developer not to implement the change as it was not approved, and explain that any scope changes must be reviewed and approved before implementation.
Sort By:
Page: 1 2 3 4 next>
Vijay -

If possible, D would be my choice as we don't want to purposely create baseline variances and the developer may be unaware of upstream or downstream negative implications of this change. By going through change control we ensure that everyone that needs to be in the know and has input into the change.

If the change has already been implemented and can't be easily rolled back, then B would be the next best option.

Kiron
...
2 replies by Stephen Morris and VIJAY KUMAR
Mar 26, 2020 5:51 PM
Stephen Morris
...
Yes, I agree with your points Kiron. Way too many chances for something to go wrong in this scenario. Unfortunately we see a lot of code like this during defect RCCA where someone was trying to do the right thing. That said, the change control process should be as agile as possible to allow innovation and creativity
Mar 28, 2020 1:57 PM
VIJAY KUMAR
...
Kiron I also thought of answer D. But the PMP training I am going through these days ( on Simplilearn) says the Answer is "B". That confused me a Lot.
The right answer is D. It is a sympton of scope creep.
I don't think this is a realistic scenario but if it has happened then I think that steps must be taken to use the work the developer has completed.

If the project is internal, that is you don't try to make profit out of it, and the sponsor is paying then the final decision should rest with him or her.

If you are delivering the project to an external entity then you must propose the change and ensure you get paid for it even if the developer worked in his spare time. If the change is not approved then you haven't lost anything as the developer has worked overtime.

The most foolish thing to do is to prevent a very good peace of work being delivering invoking project management processes. Unfortunately some times the processes prevent good work from being delivered.
...
3 replies by Kiron Bondale and VIJAY KUMAR
Mar 26, 2020 5:12 PM
Kiron Bondale
...
What defines "good" Adrian? The developer may have added the feature, but:

a) does the client want it?
b) has it been thoroughly tested?
c) does it create downstream maintenance headaches?
d) will it require upstream re-work (e.g. updating previously approved requirements baselines)?

I'm all for delighting customers and increasing value delivered, but that doesn't mean that delivery teams should be undisciplined about their way of working.

Kiron
Mar 28, 2020 2:00 PM
VIJAY KUMAR
...
Agree with Kiron.
Mar 28, 2020 2:26 PM
VIJAY KUMAR
...
One way of looking it is :
1. No cost implication due to change, but it might affect the schedule and Quality ( Differs from the agreed scope of the project)
2. Adds value to the project ( Uncertain how much value)
3. PM should encourage creativity and effort

But on the Other hand:

1. Change was only talked about and not officially approved
2. As part of Project Management one should have approved changes to execute them, which might affect the cost, quality and schedule.
3. There could have been a 5th option "E" which would be to hold on to the input from the developer and proceed for a Change request to get verified from the sponsor. Once officially approved, then proceed to integrate the change from developer.


So for me...all the answers seems not appropriate. But if I had to choose one of the four....I will go with D first.
Mar 26, 2020 3:34 PM
Replying to Adrian Carlogea
...
I don't think this is a realistic scenario but if it has happened then I think that steps must be taken to use the work the developer has completed.

If the project is internal, that is you don't try to make profit out of it, and the sponsor is paying then the final decision should rest with him or her.

If you are delivering the project to an external entity then you must propose the change and ensure you get paid for it even if the developer worked in his spare time. If the change is not approved then you haven't lost anything as the developer has worked overtime.

The most foolish thing to do is to prevent a very good peace of work being delivering invoking project management processes. Unfortunately some times the processes prevent good work from being delivered.
What defines "good" Adrian? The developer may have added the feature, but:

a) does the client want it?
b) has it been thoroughly tested?
c) does it create downstream maintenance headaches?
d) will it require upstream re-work (e.g. updating previously approved requirements baselines)?

I'm all for delighting customers and increasing value delivered, but that doesn't mean that delivery teams should be undisciplined about their way of working.

Kiron
...
1 reply by Adrian Carlogea
Mar 26, 2020 5:52 PM
Adrian Carlogea
...
Hi Kiron,

Thank you for your message.

Vijay said that the work the developer had done adds a lot of value so I assume that this answers YES at point a).

As for points b),c),d) these can be done too once the work has been completed. For example if the code was not properly tested then do test it. :)

I am not for undisciplined work but sometimes breaking the discipline can help you achieve a lot of good things.

Personally I have seen cases in which the sponsor goes directly to developers and asks them to develop something for him. When this happens the best thing is for the developers to start working immediately so that they don't loose time and the other related tasks can be performed latter.

If the sponsor knows what he wants and the developer can provide that then why should we make things much slower?
Mar 26, 2020 1:36 PM
Replying to Kiron Bondale
...
Vijay -

If possible, D would be my choice as we don't want to purposely create baseline variances and the developer may be unaware of upstream or downstream negative implications of this change. By going through change control we ensure that everyone that needs to be in the know and has input into the change.

If the change has already been implemented and can't be easily rolled back, then B would be the next best option.

Kiron
Yes, I agree with your points Kiron. Way too many chances for something to go wrong in this scenario. Unfortunately we see a lot of code like this during defect RCCA where someone was trying to do the right thing. That said, the change control process should be as agile as possible to allow innovation and creativity
Mar 26, 2020 5:12 PM
Replying to Kiron Bondale
...
What defines "good" Adrian? The developer may have added the feature, but:

a) does the client want it?
b) has it been thoroughly tested?
c) does it create downstream maintenance headaches?
d) will it require upstream re-work (e.g. updating previously approved requirements baselines)?

I'm all for delighting customers and increasing value delivered, but that doesn't mean that delivery teams should be undisciplined about their way of working.

Kiron
Hi Kiron,

Thank you for your message.

Vijay said that the work the developer had done adds a lot of value so I assume that this answers YES at point a).

As for points b),c),d) these can be done too once the work has been completed. For example if the code was not properly tested then do test it. :)

I am not for undisciplined work but sometimes breaking the discipline can help you achieve a lot of good things.

Personally I have seen cases in which the sponsor goes directly to developers and asks them to develop something for him. When this happens the best thing is for the developers to start working immediately so that they don't loose time and the other related tasks can be performed latter.

If the sponsor knows what he wants and the developer can provide that then why should we make things much slower?
...
2 replies by Kiron Bondale and VIJAY KUMAR
Mar 26, 2020 9:06 PM
Kiron Bondale
...
And what happens when the team manages to miss a milestone because of the additional scope and the work required to make it "production ready"? Will the sponsor be willing to forgive them then?

Also, why assume that the developer has actually engaged all stakeholders who need to be in the know? Often times there are control partners on the business side who technical staff may not be aware of - that is the role of a PM, to make sure the "right" people are engaged to review the scope addition.

Kiron
Mar 28, 2020 2:33 PM
VIJAY KUMAR
...
Hi Adrian...

What you say makes sense if developer is a Freelancer. But if he is part of an Organisation and team, PM has to make sure the project Plan is executed. And the change the sponsor asked for was not part of the Scope agreed, which might be, if the scope was officially approved.
Mar 26, 2020 5:52 PM
Replying to Adrian Carlogea
...
Hi Kiron,

Thank you for your message.

Vijay said that the work the developer had done adds a lot of value so I assume that this answers YES at point a).

As for points b),c),d) these can be done too once the work has been completed. For example if the code was not properly tested then do test it. :)

I am not for undisciplined work but sometimes breaking the discipline can help you achieve a lot of good things.

Personally I have seen cases in which the sponsor goes directly to developers and asks them to develop something for him. When this happens the best thing is for the developers to start working immediately so that they don't loose time and the other related tasks can be performed latter.

If the sponsor knows what he wants and the developer can provide that then why should we make things much slower?
And what happens when the team manages to miss a milestone because of the additional scope and the work required to make it "production ready"? Will the sponsor be willing to forgive them then?

Also, why assume that the developer has actually engaged all stakeholders who need to be in the know? Often times there are control partners on the business side who technical staff may not be aware of - that is the role of a PM, to make sure the "right" people are engaged to review the scope addition.

Kiron
...
1 reply by Adrian Carlogea
Mar 26, 2020 9:29 PM
Adrian Carlogea
...
Hi Kiron,

All I am saying is that if good work has already been done by a team member in his spare time and the work is useful for the project then you must find a way to integrate it.

Vijay said that the work adds a lot of value which probably means that the work would help in reaching the project's objectives.

It would be a pity to through away the work just because the process has not been followed. I have been in situations where you were unable to deliver what the users want because of bureaucratic processes that just stand in your way instead of helping you.

Wouldn't be better to let the sponsor know that the work has been performed and if some extra work is approved then great value would be delivered? The sponsor then can decide if it goes ahead or not. Anyway no resource was used since the team member worked in his spare time.
Mar 26, 2020 9:06 PM
Replying to Kiron Bondale
...
And what happens when the team manages to miss a milestone because of the additional scope and the work required to make it "production ready"? Will the sponsor be willing to forgive them then?

Also, why assume that the developer has actually engaged all stakeholders who need to be in the know? Often times there are control partners on the business side who technical staff may not be aware of - that is the role of a PM, to make sure the "right" people are engaged to review the scope addition.

Kiron
Hi Kiron,

All I am saying is that if good work has already been done by a team member in his spare time and the work is useful for the project then you must find a way to integrate it.

Vijay said that the work adds a lot of value which probably means that the work would help in reaching the project's objectives.

It would be a pity to through away the work just because the process has not been followed. I have been in situations where you were unable to deliver what the users want because of bureaucratic processes that just stand in your way instead of helping you.

Wouldn't be better to let the sponsor know that the work has been performed and if some extra work is approved then great value would be delivered? The sponsor then can decide if it goes ahead or not. Anyway no resource was used since the team member worked in his spare time.
...
2 replies by David Portas and Kiron Bondale
Mar 27, 2020 3:40 AM
David Portas
...
I agree with Adrian. Whether or not to include something in a release is a Product Owner decision. Developers ought to be collaborating daily with the PO so there should be plenty of opportunity to discuss it. Many teams do adopt the practice of having an open-ended backlog where it's accepted that anyone can add new items for consideration.

One person developing something on their own is not likely to satisfy any Definition of Done. So the feature is not actually "complete". It could and should be considered for the next iteration or a future iteration however.

C,D options sound equally undesirable. A is about paperwork rather than practicality. B is perhaps the most positive course of action of the options given although I wouldn't put it in quite those terms.
Mar 27, 2020 7:48 AM
Kiron Bondale
...
David -

the question didn't mention a PO. In any event, if the team is following a framework like Scrum, the backlog is expected to be the source of "truth" as far as what the team works on. Unless this item made its way to the backlog and had been appropriately prioritized by the PO, the developer should not have jumped on it.

Adrian - I'd agree that at this point the horse has left the barn so assessing the impact of this addition and making the sponsor aware of the total impacts would be needed. That would normally be done through project change control.

Kiron
Mar 26, 2020 9:29 PM
Replying to Adrian Carlogea
...
Hi Kiron,

All I am saying is that if good work has already been done by a team member in his spare time and the work is useful for the project then you must find a way to integrate it.

Vijay said that the work adds a lot of value which probably means that the work would help in reaching the project's objectives.

It would be a pity to through away the work just because the process has not been followed. I have been in situations where you were unable to deliver what the users want because of bureaucratic processes that just stand in your way instead of helping you.

Wouldn't be better to let the sponsor know that the work has been performed and if some extra work is approved then great value would be delivered? The sponsor then can decide if it goes ahead or not. Anyway no resource was used since the team member worked in his spare time.
I agree with Adrian. Whether or not to include something in a release is a Product Owner decision. Developers ought to be collaborating daily with the PO so there should be plenty of opportunity to discuss it. Many teams do adopt the practice of having an open-ended backlog where it's accepted that anyone can add new items for consideration.

One person developing something on their own is not likely to satisfy any Definition of Done. So the feature is not actually "complete". It could and should be considered for the next iteration or a future iteration however.

C,D options sound equally undesirable. A is about paperwork rather than practicality. B is perhaps the most positive course of action of the options given although I wouldn't put it in quite those terms.
Mar 26, 2020 9:29 PM
Replying to Adrian Carlogea
...
Hi Kiron,

All I am saying is that if good work has already been done by a team member in his spare time and the work is useful for the project then you must find a way to integrate it.

Vijay said that the work adds a lot of value which probably means that the work would help in reaching the project's objectives.

It would be a pity to through away the work just because the process has not been followed. I have been in situations where you were unable to deliver what the users want because of bureaucratic processes that just stand in your way instead of helping you.

Wouldn't be better to let the sponsor know that the work has been performed and if some extra work is approved then great value would be delivered? The sponsor then can decide if it goes ahead or not. Anyway no resource was used since the team member worked in his spare time.
David -

the question didn't mention a PO. In any event, if the team is following a framework like Scrum, the backlog is expected to be the source of "truth" as far as what the team works on. Unless this item made its way to the backlog and had been appropriately prioritized by the PO, the developer should not have jumped on it.

Adrian - I'd agree that at this point the horse has left the barn so assessing the impact of this addition and making the sponsor aware of the total impacts would be needed. That would normally be done through project change control.

Kiron
...
1 reply by David Portas
Mar 27, 2020 9:31 AM
David Portas
...
Hi Kiron,

The question doesn't mention any business owner but someone should be responsible for decisions on business requirements and priorities. In Scrum that person is the PO.

In Scrum the team works on the sprint backlog which is defined by the development team and they are free to add to it during a sprint. The PO does not control the sprint backlog. However, as I mentioned, teams are often encouraged to add items to the PB as well. As you say, the PO should decide on the PB priorities and that would the most appropriate way to consider proposals for new items for a future sprint.
Page: 1 2 3 4 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

I don't like to carry my wallet. My osteopath says it's bad for my spine. Throws my hip off kilter.

- Kramer

ADVERTISEMENT

Sponsors