Thoughts about fixed-priced projects

Negotiating is domain area, which for most people is much more complicated to deal with, then even the most challenging technical task.
Once during one of our Agile club we have discussed fixed-priced contracts and applying agile methodologies to them.

This was quite hot topic: audience consisted of mainly agile adepts, but the projects they were involved indeed where fixed-prices.

In generally that discussion is not worth to retell it entirely, but there were some thoughts that may be very much valuable for me.

1. Above all, fixed-priced projects are normally more expensive and that means they are potentially more lucrative for executor (for IT company or team that works on them). It's a high price for professionalism. If I were millionaire I would rather have 100% service for 100% price:

I don't need analysts, testers, QA, IT department from my side to support YOUR development. I don't care if it's 400% more expensive: just give me entire calculation and risks and I will put your proposal under consideration.

So team has a good opportunity to provide product owner from their side and to make fair product for good price.

2. Commit or not commit that the question.
And all risks should be calculated before project is started

Here I have exposed one more thought: can we reuse that approaches that is used by venture capitalist when they do their business in IT
Unfortunately not: normally venture capitalists' approach is to be aware and to be acquainted with people: but they have money to take over risk, we don't :(

3. Fixed price project can be conducted as agile projects, but all necessary infrastructure should be provided by executor.

One of my colleagues proposed idea to specify if customer is opened or not. So if he ready for communication that better if he is not.

I also had thought about that: but I'd rather just exclude projects that depend on single non-responsive person as not good for me.

Just make me happy and don't ask any questions.

If your customer is large organization it's not a big problem if they are remote and not responsive. I've seen so many times when customer's representative not provided enough analyst or information about their product or requirements. But I have never seen customer that forbade their coworkers to speak with our coworkers.
Even in the worst case you anyway can talk with them, have discussions, drink bear or date their office managers.
You do have chance take information about how to make them happy (unless your customer is not Jesuits Order).
The costs of all this is a different thing. But since account management has word "presentation costs" normal business used to work with them, so IT business also have to.
So, viva forever! :)

Who should take care about negotiations?

Yesterday I was blamed by my boss because of using term "collective opinion" during meeting with customer. How strange, three years ago I blamed myself for thought that "collective opinion" actually exist. I consider this as something very rudimentary inherited from old Soviet times. And my chief actually shares this idea

In civilized society there is no entity like "collective opinion". It would rather be an opinion of your self-important ego

There was indeed more ado about this, but generally I can assume two basic reasons why "collective opinion" is to be blamed:
* Collective opinion means someone talks as representative of others, who apparently where excluded from the discussion
* Collective opinion means that nobody can take over responsibility for what is said.

My questions I would like to raise are:
* What is collective opinion in "civilized world" in general?
* What is collective opinion in Agile context?

I concluded that collective opinion as term should not be so bad surprise civilized world. It accepts terms like collective security and Agile community even sustains having so called collective ownership. Collective opinion not necessarily brings you to chaos of responsibility, like collective ownership does not. In XIX century Gustave Le Bon noticed that collective opinion exists and sometimes brings to very positive (sometimes to very negative :) ) results. The most great distinction was discovering that sometimes collective opinion is biasing from average opinion of people that are "collected". The next great thing Le Bon discovered is that rules how collective opinion (or in general collective mind) is built up can be investigated and used. Since his lifetime there are many different things emerged: Dale Carnegie practical psychology, people management in XX of Peter Drucker, new approaches in XXI century, public relations (both white and black) and so on: nowadays we have huge set of methods to bend collective opinion to some certain way and approaches to control collective mind. So even people suffer hearing about collective opinion, we should admit that it exists, it is used and will be used until humankind lives ...

What about agile? Can it mitigate parasite usage of collective opinion?

What 2 of 4 principles in Agile Manifesto declare emphasizing on Individuals and interactions, from one side, and Customer collaboration, from another. So Agile pretty straightforward about who should negotiate with customer:
as many and as much as team member can.
Agile suggests having egalitarian team with equal rights and possibilities to make a contribution.

That's very logical: in idealistic situation all team members can ask responsible person about this or that and use his (her) decision to go ahead ...
What about reality? Customer (Product Owner in SCRUM) is indeed very complicated role in Agile: I know few cases when we really had proactive product owner that was able to answer incoming questions team need to ask. But in most of cases product owner is not motivated enough or doesn't have enough administrative power/time/resources to make decision or team members are not skilled enough to ask "correct" questions (Correct is not that word, probably to be exact I should have used figure like questions, that bring us to correct decision in the shortest way).

In our situation when team members are not acquainted with product, distant from customer and have language barrier this trouble is even bitter. More negotiation skill of team members are very different: some people can hardly speak English ...

One friend of mine says that the key is to have proper people in team. That would resolve the problem.
But people can never be ideal!
Can we make team better than people we have?
Some people call this synergy (collective benefits prevails the sum individual benefits). Can it be applied here? How do you think?

Agile team egalitarian, but it doesn't necessary mean that all should have the same activity. One of us is better in DB administration, somebody in designing UI, somebody in investigations, why can't we consider negotiations as one more branch we can play with. What if you have in team guy who probably not so good in developing software but can do following things better than others:
* explaining how software should work to team
* explaining how it actually works and how it can be changed to customer
I would say that it's better to have such team member than to not have. And it's better to keep him more organizing negotiations than to try to smooth distribution of negotiations between different other people.

Some investigation I would like to do, will show how it works ...
(if it indeed works)