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--------------------

Priority vs Severity vs Impact

I have come across multiple project managers and teams managing Level 2 and Level 3 IT support projects who struggle to articulate the EXACT definitions of Priority, Severity and Impact. Also these 3 terms (especially Priority and Severity) are used interchangeably by project teams. Here is my small attempt to explain the same with some examples.

Impact is the way in which an Incident affects the core business or revenue of the organization. A high impact defect has the potential to stop core business operations or even cause revenue losses. Typically Impact of the Incident does not change with time. Below you can see sample definition of various levels of impact. These can be changed or modified as per the business you or your team is supporting.

1-High: Defects resulting in failure of key Organization business processes impacting revenue. There is no work around available.

2-Medium: Defects impacting business processes. Key components are down and major functions are not working. No immediate / serious impact but has potential to affect revenues. Unreasonable work around exists.

3-Low: Defects impacting functions that have a low/negligible impact on key business process. Reasonable workaround exists.

Urgency suggests the amount of delay acceptable in resolving a particular incident and is always associated with time. A high urgency incident will have minimal acceptable delay in resolution. The Urgency of the Incident can increase as the age of the Incident increases.

1-High: Very urgent incident which should be treated as quickly as possible

2-Medium: Urgent incident which should be treated quickly

3-Low: Incident that is not urgent and resolution can wait for some time

Priority is defined as a combination of Impact and Urgency (Priority=Impact X Urgency) and is defined as per the below table

	Impact
Urgency		1-High	2-Medium	3-Low
	1-High	P1	P2	P3
	2-Medium	P2	P3	P4
	3-Low	P3	P4	P5

Below example will help you to understand the above definitions better 

Example: Incident logged that a particular feature has to be added on www.phutwa.com site effective 31-Dec which will increase user hit rate on website. For this to happen QA team need to provide sign off on this feature in lower environment by 01-Dec. Development team started working on the feature, but while testing it in lower environments team found it had some defects.

• 01-Nov: On 01-Nov, the defect will have Impact: Medium, Urgency: Low
• 20-Nov: If still unresolved, Impact:Medium, Urgency will change to  Medium
• 30-Nov: If still unresolved, Impact:Medium, Urgency will change to High

In the above example Urgency of the defect remains same but its Urgency keeps on increases as we reach near to a critical date of 01-Dec.

Hope the above definitions and examples will clarify the differences and relations between all 3 terms. Please feel free to comment with your views.

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