Gopal SahaiCorporate Trainer| Self employedNew Delhi, Delhi, India
Scenario: Internal automation projects
Key Stakeholders: Head of the Organization and Functional Departments.
Project Org Structure: Functional
Background: Many of us have experienced the challenge to deal with Gold Plating and Scope Creep. Especially true for internal projects influenced by Organizational Culture, gold plating is largely self driven (from project inside-out), whereas scope creep has come in from outside (stakeholders wanting more). While controlling gold plating is still manageable, scope creep coming from higher ups is a real challenge; esp. when the same stakeholders later complain of project delays and project mis-management. Eventual impact on team performance and appraisal.
Question: How to manage such situations on stakeholder expectations, both pro-actively and reactively. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Sorry to disagree in one poimt (and sorry if i missumderstood). Agile environments will not prevent this. Change control still remains the key in agile environments. When i am talking about agile i am not talking about a method or about software only.
...
1 reply by Gopal Sahai
Mar 18, 2016 7:56 AM
Gopal Sahai
...
Disagreement welcomed.. keep them coming. Good to have differing views.
Change Control (on scope, as well as behavioural) is definitely the key. I guess what Thomas Walenta wants to emphasize here is by having an iterative (rolling wave) planning, it would help the project manager - as well as the stakeholder (esp applicable to internal projects) take each small change proposed by them and understand how it impacts the overall project success. Such stakeholders (esp internal), may get better 'handled' for their requirements 'creeping' into the project, if handled in agile manner. At the end of the day, value needs to be delivered and 'stake'holders have their bit of stake (read, responsibility).
That said, I would really want Thomas Walenta to express his thoughts, if rightly captured by me and how Sergio Luis Conte's views can align with the approaches being discussed on the subject.
Saving Changes...
Gopal SahaiCorporate Trainer| Self employedNew Delhi, Delhi, India
Mar 18, 2016 7:30 AM
Replying to Sergio Luis Conte
...
Sorry to disagree in one poimt (and sorry if i missumderstood). Agile environments will not prevent this. Change control still remains the key in agile environments. When i am talking about agile i am not talking about a method or about software only.
Disagreement welcomed.. keep them coming. Good to have differing views.
Change Control (on scope, as well as behavioural) is definitely the key. I guess what Thomas Walenta wants to emphasize here is by having an iterative (rolling wave) planning, it would help the project manager - as well as the stakeholder (esp applicable to internal projects) take each small change proposed by them and understand how it impacts the overall project success. Such stakeholders (esp internal), may get better 'handled' for their requirements 'creeping' into the project, if handled in agile manner. At the end of the day, value needs to be delivered and 'stake'holders have their bit of stake (read, responsibility).
That said, I would really want Thomas Walenta to express his thoughts, if rightly captured by me and how Sergio Luis Conte's views can align with the approaches being discussed on the subject. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Good. But take into account,that,agile is,not a life cycle. You can apply agile,with,waterfall life cycle,models. And let me say that, what you stated can make scope creep and gold plating growth exponemtially. I just write here other point of view based my experience in those environments an my research. And generally speaking but you stated could make things works better indeed. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Sergio,
in my opinion and that of PMBoK Guide, agile methods are considered a project life cycle, an adaptive or change-driven one. See PMBoK 2.4.2.4.
Agree with you, that you can apply agile also in mixed modes.
Scope creep is defined as 'uncontrolled change to scope'.
In agile, scope per se is not defined upfront, but progressively developed during the project. Changes are in pure agile, e.g. scrum, fully controlled by the processes dealing with the product backlog. So there are per definition no uncontrolled scope changes and hence no scope creep in pure agile. This is different for mixed environments. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Gopal,
think for rolling wave planning, you are trying to define scope in detail only for the next time period and high level for the subsequent time periods.
This means, it is easier to control the scope for the near time period, as you just do not allow the stakeholders to have too much time to make up their minds differently and the amount of scope at stake is less than the full scope. For the high level scope this is also true, you do not grant many options for changes on this level. (e.g. build a house next year could be changed to buy a car next year, but this is easy to handle now, if you did not fall in the trap to plan the house in full). If stakeholders want to detail this high level scope, just reject it (or put it in the parking lot until the time comes to detail this part).
You can only control what you planned for. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Thats the problem, pmbok is wrong. Dont take my,comments. Search,for agile origin in USA DOD/NSF AGILITY Forum (i was,part). Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Sergio, for me its not a religious discussion of wrong or right.
There are errors in PMBoK but this is not one of them, it is a deliberate decision of PMBoK how to classify and deal with agile and still to maintain their structure set since 1996. One benefit of this that PMI educated people can build on their existing knowledge and still understand evolving topics like agile. PMBok and other concepts try to model the world and all if them may be right and even useful in certain situations. Models are most useful for the public if they are stable.
PMBoK contained agile elements of iterative and progressively elaboration even before the agile manifesto was published, so it may have been influenced by the work you mentioned. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
For me is not a religious discussion too. The problem is when people like me, that are leading my seventh initiative to implement agile (not software, not IT, not method or life cycle. Really agile) in the organization are living with missunderstanding that jeopardizes a serious work. Agile is nothing to be with interactive because is nothing to be with life cycle. PMBOK is fully compatible with agile principles as is. And the worst thing that Gopal can do is thiking that agile will solve god plating or scope creep or more than this: do not undestand what agile really is. But that is my opinion based on my work (I worded with agile from the very begining because I was part of the Agility Forum and I was part ot the group of authors of version 1 and 2 of DSDM agile development method) and because I do not own the truth (thanks God) any other person can take other path to do things. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Sergio, no threat intended. Sorry for my German bluntness.
I am currently working with a IT company which successfully implemented scrum for one area but struggles to extend this to other areas. In that area, they (IT) absolutely have no scope creep, since the product owner from business takes full responsibility to manage the backlog. I agree that the business still has the problems of scope definition, change etc., but IT is happy, which translates to happy scrum teams and high velocity.
This for me is a successful model.
I still did not understand what you are doing and how that makes scope control a necessity. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Thomas, I am located in Argentina, South America, so my english is a disaster. Please sorry if I have sound rude. For me is a pleasure to take this conversation with you because I spend my time in this type in this type of sites to learn from others. Generally speaking I agree with you. What I tried to say is that in methods like SCRUM scope control is there, implicit or explicit inside the method itself. The same with change control. Saving Changes...
