Fixed Price Projects - My cup of Tea ?

"I don't have good Gross Margins for my project"

"Customer keeps on changing the requirement"

"This requirement was not written in the document"

"Sales team undersold this project"

"There are contractual flaws leading to less margins"

Sounds familiar ?

Today IT landscape is changing drastically and so is the customer. Customer want to do more and more projects in a fixed price fashion. There are majorly 2 reasons of this:

• Safeguard the budget
• Not enough trust built between customer and vendor (specially in case of new projects)

So let me come to the point. In this article I will try to recommend few ways that can help to answer few of the above questions so that it is a WIN WIN for both customer (gets what he wants) and vendor (delivers with good gross margins). First thing first. Half of the battle is either won or lost in presales phase. Let's talk about it a bit.

Pre-sales

---

Requirements

• If requirements are not elaborate, ask questions (lot of questions), educate customer to help him include implicit requirements (e.g. sorting, pagination, filtering etc. in case of a UI requirement)
  
• Invest time of a Business Analyst to refine customer requirements. Believe me this investment will go a long way both to elaborate requirements and even avoiding ugly clashes later in the project (on implicit vs explicit requirements)
• Always remember most of the time customer will provide a Business Requirement Document (WHAT he wants) and estimation should not be done without converting it into Functional Specification or a detailed Use Case Document (HOW and a flow of use cases)
• If there is a end to end product that needs to be build, it is always good to have a Minimum Viable Product (MVP), which can be a Fixed Price. In this phase a good rapport can be built post which rest of the product can be built in a T&M mode.

Contract

• I will recommend for a Business Analyst in a project to be billed who will be team's face for discussing any requirements with customer else we end up taking a risk of Change Requests leaking into the team (customer talking directly to developers is a very common case) without a Scrum Master aware of it.
• Better to add a contingency in the overall effort to safeguard the situations where unexpected requirement (implicit requirement) that is not planned for
• If part of the team is expected to work in customer timezone, same have to taken care in terms of cost of the resource
• When few projects are already under execution phase, we are tempted to assume that we will use an existing Project Manager and hence do not plan for his/her cost in initial deal. What if your new project gets signed off a bit late and by that time your previous project has ended? I guess you know what to do. So better to plan for this kind of a situation.
• Acceptance criteria is normally not defined well and invoice milestones are linked to Acceptance criteria. e.g. "UAT sign off" is stated as one of the acceptance criteria. It should be as quantitative as possible like "No P1/P2 open defects"
• Cost of delay: This probably is a very important clause that can help all teams to make sure they are delivering on time. 

Development

---

• Try to on board the team in a staggered manner to avoid a lot of cost upfront. This also helps for Senior members to define some ground rules. Getting too many people at the same time can be counter productive.
• Add Change Request process to be part of kick off presentation, so that the definition of Change Request is mutually agreed between all parties to avoid conflicts later.
• Avoid Change Request leakage. In case of a change request be as objective as possible and have an open discussion with customer.
• Most common and most difficult way to control cost is by doing Pyramid correction. Try to have a good mix of team experience
• Try to cross train team members
• In case teams are working in shifts and are coming in company cabs, make sure to cancel cabs in case someone is on leave. This is a small amount but still impacts your bottom line

Hopefully this will help get answers to some of the points we discussed at the start of this article. Please feel free to share your experiences.

--------------------X--------------------