Bidding In Software Development
Bidding In Software DevelopmentBidding in Software Development
Bidding will occur at each level:
Can such an approach possibly work? -- Have methods similar to this worked in current practice?
It has worked: In Union organizations, bidding for positions has been successfully utilized for years. In the union case, the winning factor is that the person qualified with the highest seniority wins. In software development a different mechanism and power rating is to be employed. (Most years of experience, Familiarity with the area and emphasis demonstrated by past successes, track record, etc)
What if any are the strengths? The selection process can be activated from both ends. The Project can define what the resources are required and can evaluate those bidding on their strengths and apparent ability to perform. The Developer or programmer can select based on interest in the type and duration of the project along with the workability with the Project's initial team members based on knowledge and history. One simply would bid only on those projects meeting personal and professional goals.
What are its weaknesses? There are several weaknesses to this approach, one of which is that Unpopular projects and initial structure may result in No bids being offered. Another is that management is somewhat out of the loop in the project staffing by submitting to the willingness and acceptance of the developers and programmers desires.
Discussion:
Bidding is used in business all the time to determine the supplier chosen by the Project Management, Engineering, and Procurement. It is not always based on lowest bidder, but often takes other important factors into consideration. I can appreciate that such a method works in that context, but do not see how it can be implemented in SoftwareDevelopment.
Why on earth not? Companies like to know what the credentials of their supplier are, and what they're getting. So supplying references, discussing their financial situations, agreeing statements of work are all still relevant and a bidding process is a reasonable way to do that.
Many of leaders in manufacturing quality have argued against the bidding process described above. They argue in favor of single suppliers and long term relationships. If you have a known supplier (or developer) you know what to expect. If you have a long term relationship, you can work with the supplier (or developer) to improve what it (he) provides.
I can see this to be true if the procurer is large and the supplier is small, where the procurer is the designer and the supplier is the manufacturer of parts. Can this model also apply where the procurer is small and the supplier is large?
Relative size only matters if you are concerned with manipulation. It is not possible to coerce a person or a company into producing quality, he or it must learn how to constantly improve the quality of its products and this can only be accomplished by listening to the customers. The other key point is predictability. With a given team of developers, I can predict about how well they will perform and how long they will take to complete a task. With a team of unknowns, I can only guess.
It also depends whether this is a one off (or even a several-off) or if there's a long term relationship needed. There's a difference between choosing a core supplier for gearboxes for your cars for the next decade, and choosing a software development company to develop a web site for your next big promotion.
The original point in the discussion says do not see how it can be implemented in SoftwareDevelopment. That's a rather different point from saying it's not the optimal way.
I'm intrigued by the title, but I don't understand what is being proposed. Is the idea that developers within an engineering group would compete against each other for the opportunity to do various projects or tasks? How would the requests for bids be made, how would the bids be delivered, who would decide on the winning bids and by what criteria? If this isn't what was meant, what was meant? Please help me understand with an example. -- ChrisBaugh
How would this work if you do not have a pool of developers without current assignments?
I've thought about this for a while, particularly w.r.t. UnitTesting (not exactly the same as XP's UnitTests). The idea would be that a list of the units to be tested, along with an interface specification, detailed design docs and VerificationRequirements would be advertised (probably via the web), and bid's invited for carrying out the UnitTesting. Prospective testers could then look at the provided information, and provide a quote for doing the work - possibly they may quote for a number of units. The project then decides who gets the work based on the quoted price and the testers track record.
Some attractions (incomplete list):
This is already being done. See
Related concepts: SelfOrganizingTeams
EditText of this page
(last edited December 1, 2014)
or FindPage with title or text search