September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
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.
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.
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.
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?
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.
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.
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.
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.
Please login or join to reply