How to handle customer''s attempt to push out of scope items in the name of agile? And does being responsive to changing customer requirements mean taking on more work even if it either reduces the project''s profitability or is economically undesirable? Saving Changes...
saurabh mahajanPMP, ITIL, PRINCE2| vodafonePune, Maharashtra, India
Great question. This always happens but. Some time in project, project management team forgets that there is thin line between what needs to be accepted and what needs to be declined.
To check and confirm what customer is demanding is really a legitimate demand, the best way is to go back to project charter/business case. This will answer why this project was initiated. If this results in "YES" then accept the demand. If results in "NO" then promptly raise this to project manager. Substantiate it with the requirements mentioned earlier. show all the project management plans (this should not have the legitimate demand)
To your second questions:
If planning was done in detail then questions of "project''s profitability" or "economically undesirable" should not come in between. Again your business case should have mentioned somewhere the profit that will gained by taking this project.
But the out of scope demands if fulfilled will hamper the intended result surely. Saving Changes...
Thanks for the answer, it definitely makes sense. As all the practicing PMs in IT domain would know that this is a real life scenario which happens often. I agree with you that the project charter should be the guiding document and we have to keep in mind that Agile does not mean accepting ALL demands of the customer. Saving Changes...
Very good answer. I just need to add that there could not have been any detailed planning in Agile. The planning done at the outset is outline but still the business case or the need dictates the justifiability or feasibility of the project. All changes are not to be accepted at face value and must go through a change management process, no matter how fast they can be processed but they must pass through it. Only changes that make sense for both the parties as well as aligns to strategic objectoves should be accepted. Saving Changes...
I agree, there could not have been detailed planning in agile. Another point is that maybe the change satisfies the business case and is relevant to the project, however the effort and the cost have not been taken into consideration during initial pricing and the customer however enthusiastic about the functional change, most often would be reluctant in its reflection in the price change. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
These answers assume a traditional PMBOK approach and are not attuned to agile thinking.
First of all, the project charter is not the guiding document. The customer is your guide. In this context, "customer" can mean a number of people, so to be more precise, I''ll use the Scrum term Product Owner to mean not just anybody in the user community, but the person who is assigned to your particular project and who has the responsibility for populating and prioritizing the product backlog from which the development team works.
Going back to the project charter is an exercise in futility when you have an actual Product Owner engaged with you or your team. Why would you try to glean "what the customer really wants" from a months-old document that by definition is high-level and incomplete, when you can simply in real time ask the Product Owner instead?
In agile, we accept that what was captured up front in the project charter (if one was prepared at all) can change. Our best understanding of what the customer wants is always what the customer, i.e. the Product Owner, says that she wants in the here and now. We trust that what she wants today is better and more correct than what she thought she wanted at the beginning of the project, before she had feedback from repeated iterations of actual delivery of the desired project deliverables. Don''t go back to the project charter, talk to your Product Owner!
Second, the project''s "profitability" is not really the concern of anyone except the Product Owner and the executive sponsors above her. As far as the development team is concerned, the Product Owner is the sole judge of value being returned by the project team''s activities. If the Product Owner determines for example, that you should implement features A, but not feature B, then that''s what you do. If the original project vision as captured in the original plan (the project charter, or the original version of the product backlog) only included features A through E, but the Product owner decides during the project to include additional featured F through M, then that''s her prerogative. She''s responsible for the budget and the "profitability" or business value delivered by the project.
As you can see, the traditional project manager is sidelined a bit here, as he no longer has responsibility for deciding what should be done, what order things should be done, or whether it''s worth doing them in the first place. The role of the Customer or Product Owner does this in agile projects, and this is as it should be, as the customer should always be the one empowered to control spending and to judge the value to the business of the product being delivered. The Project Manager is a poor substitute for the customer in this regard. Saving Changes...
Bruce Wilkinson MBA, PMPExpert Project Manager / Trustworthy Executive Assistant / Business Coach| goBRUCE Business ServicesCuenca, Azuay, Ecuador
One take-away here could be that Agile might not be ideal for every kind of project. Projects with a fixed budget might need a defined scope. Saving Changes...
Alistair, I agree with what you say and essentially Agile differs from the traditional project management approach at a fundamental level of the roles, however when in a project more than one organization is involved - customer and vendor, the needs of customer might be in conflict with profitability of the vendor. And at some point being responsive to customer''s needs would mean that the project becomes nonviable or at least unattractive for the vendor. Here if the Product Owner is from the customer organization (as mostly would be) then she would not be as concerned about vendor''s profitability and hence her word could not always be final about what should happen in the project.
I would agree with Bruce, that maybe Agile is not suitable for all projects and in a fixed cost contract it would be wise to go with more detailed scope. Yet the popularity of Agile means there needs to be balanced approach with a mix of Agile and traditional methodologies. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
I wouldn''t say necessarily that projects with a fixed budget need a defined scope. I think that the fact that you have a fixed budget doesn''t mean that you can''t deliver in an agile fashion. Assuming the team size and other variable costs are stable, then a fixed budget simply means a fixed number of iterations are available for delivery.
I would say though, that if you have a defined scope, then you may not need agile to manage your work. I''m biased though, and think that agile approaches are better in almost all situations! Saving Changes...
Having a fixed-cost project is a way of risk management of the customer. The vendor should take all necessary measure to cover the risk taken by accepting that type of contract, and one way is to have a very well-defined scope of the project.
If you still looking to adopt an Agile approach of the project one way is to have a very clear Product Backlog defined with the Product Owner. This backlog should be very well maintained during the project and all Items should be classified (using MoSCoW for example), prioritized and estimated. In the case of a change in one Item priority and classification you should maintain fixed the effort estimation by reducing the priority and classification of other Items in the Backlog.
Very important for you as a vendor is to adapt also the Contract Agreements to Agile Methodology used. I can recommend this approach: http://www.agilistapm.com/fixed-price-contracts/ Saving Changes...
Bruce Wilkinson MBA, PMPExpert Project Manager / Trustworthy Executive Assistant / Business Coach| goBRUCE Business ServicesCuenca, Azuay, Ecuador
Silviu, thank you for bringing this article to our attention. This article has great value, and is one of the better attempts to run fixed-cost projects with an Agile approach that I''ve seen. I did note that making it work depends a lot on trust and customer flexibility which could be challenging for the project manager. For anyone interested in this topic, the article is definitely worth taking some time to think through. Good one Silviu! Saving Changes...
