RFP Guidance to Product Owner
We are mid sized SME, relying more on commercial software. We have a need to build new product and PO is preferring to float a tender/RFP. He knows the feature lists and some timeline/budget in mind. Being Scrum Master, i don't like RFP much since it creates fixed constraints. I also believe that at the start there are more unknowns than known. If we go on RFP, I know that later, more discussion will be on satisfying the contract rather than collaboration.
What advice should i give to PO? I cant just simply say RFP are not good, where lots of discussion on Agile Contracting are happening around the globe.
You are correct, fixing scope, timelines and cost doesn't work when building complex products. It didn't work in waterfall, and doesn't work with Scrum. It is irresponsible and not professional. Often times the RFP is filled with padding of hours to make up for the unknown (is padding being professional?). If there isn't padding, the teams either suffer a death march to meet the date, and/or corners get cut (e.g. quality, tech debt builds up).
There is a lot of discussion happening around Agile contracting. Google some of the patterns such as 'Money for Nothing and Change for Free'. Bring some of those ideas to the conversation with your PO. Look for a win-win between your company and the customer. You can still have fixed dates and you'll know what the labor costs are per Sprint, but you will have to consider scope being the variable piece. Most likely the customer is going to ask for changes as they see the product being built, and they will appreciate the collaborative approach of being able to have flexibility with Product Backlog scope and order.
Use the Scrum value of courage!
Wishing you all the best.
What advice should i give to PO? I cant just simply say RFP are not good, where lots of discussion on Agile Contracting are happening around the globe.
Wonder about the uncertainty that is there, and how the RFP would accommodate it. Perhaps it can be framed as a challenge. How would the successful contractor handle emergence? If your company was to buy Sprints, which supplier would make best use of them?
Wonder if it is more important to try and offload risk onto the supplier -- a common though rarely productive strategy -- or more important to collaborate for a successful outcome.
From my own experience working in Fixed Price projects, The result was always failure. Either the scope was not completed or it is completed(by counting the deliverables in given timeline) but the quality was poor in production.
Example 1, A Fixed price project was planned to run in traditional model with well certain scope as it was kind of reengineering in Mainframe systems. The client and vendor management was very certain about the plan to complete.No direct customer facing modules but the technical complexities on the way has slowed down the progress and finally the results were not as it was expected to be.
Example 2, A Fixed price project was planned to run in Scrum model using a well established third party tool in the market. They only know the end product but neither the client nor the vendor has experienced in such kind of large implementation using that tool. But still for some reasons both the managements has planned to do it in Fixed price.
Some of challenges faces:
1. The vendor will charge CR if you want to do incorporate any sprint feedback from stakeholders. This applies not only for stories but for architecture and design. So I didn't see any value in sprint reviews. There is no CR in Agile but Fixed price model has it.
2. Team can not implement every valuable features due to the technical limitations of the tool. The vendor team will easily divert it on tool and if you chase the tool support to enable any feature you have to wait for their next release. Of course this happens in any project, But in Fixed price you need to pay even if the vendor team sits ideal.
3. PO is not empowered to act on his decisions as the Vendor Project Manager will sit on teams head pushing to complete whatever planned. But it is not always happens as per Ghant chart
4.How to measure the progress against contract ? Number of stories completed in the backlog ? Fixed velocity ? You will not know what customisation of tool is needed when you sign the contract. Then always it will be a contract negotiation
5. Moreover the management level blame games will bring bitterness at team level as well. So collaboration with client and vendor team will be more formal way.
More like this.. And when we learned this way will not work, Half of time was over. Management spent rest of the time in changing the contract type.
So it may look like profitable approach for your PO before the start of project, But his time will be taken for following the contract not product.