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! :)

Where to start building up solution?

    We have passed kickoff negotiations and concluded that we have keep on building new platform from sketch. Our team and customer is leaning to be agile as possible, so we immediately started from elaborating use case. Our initial plan is following:

1. Login to the system
   
2. User management tool
   
3. other ...
   

    Is it a dream? Or deja vu? I have seen so many projects which started namely from those two items: login and user management, that I think there must be something enchanted and supernatural in those items.

Why login and user management is so important?

    Although login functionality is in 90% cases are the same (login, password, attempts to login before being locked and forget password, of course: nothing special) everybody wants to start from this. Probably because it's very evident part of the front page of any website.
    But pay your attention: this is nothing that can distinguish your web solution. In fact if you want to place on front page your logo and news and public speech of your CEO it would be further more recognizable and authentic. Don't you think so?
    Ah! I see: you still not sure what kind of info should you place on the front page. That makes difference: probably let's do easy start with login and password fields
    What then?
    Yes, sure we have very very sophisticated user management. Here how much roles we have, how to assign roles and groups to user, how to specify and handle rights of them on reading, writing and view profile of the assets?
    Wait a bit! Do we REALLY have assets in our system? Or any other entity? And do we really know what END-USER should see on our web page?
    In a second I realized an evidence: we DO NOT KNOW what our final user is going to see, but we already put efforts to build up user management tools ...
    I have a question: what kind of user do you have in your system? The answer would be (let us imagine a bit):

1. Administrators
   
2. Extended users
   
3. Normal users
   

    And what is distribution of those users?

    Can you believe that? Our users are mostly common users and they are community we creating system for! Why do you so anxious about administrator UI, rights, obligations and privileges until you don't know what user should see?
    Well, administrator is a God in system and if we wrote Bible today we probably started from definition of God.
    This may be a reasonable way to found new religion, but enterprise system is not The Universe and not something we should worship (Sometimes it is really considered to be like this). Let's try to think another way: try to imagine what your usual user should see in your system. Do you have a few arguments why he actually should use the system? And finally if you have perception about

• what user should be able to get from the system (features and information)
  
• what user should be not able to get from the the system (security)
  
• what is our benefit in the system?
  

    Does it mean that you can find out what is needed from user management, security, automation and so on just if you know aforementioned points?
    You probably will blame me, but my personal answer on the latter question is YES. Indeed, security rights, user management or any other management exist to allow user to have services they want to have, charge them for those services and to not allow them make harm to other users and system itself ...
    Even if your system is difficult for administrating but very friendly to end-user it can have success, but if it's not friendly to end-user whatever you have in back office it makes no difference for outworld anymore!

How should we start?

    Ok. Let's try to start with very small things ...

    I have a question: what kind of user do you have in your system? Answer is

1. Normal users
   
2. Extended users
   
3. Administrators
   

    Oh! That's much better! Let us think about normal users first :)

Good luck!