Thus far in this series you've learned about the benefits of agile processes and the requirements placed on the organizations that use them. You've also learned how organizations adapt to agile development, about the different types of stakeholders, and how to apply user stories. You walked through a case study and saw how user stories, discussion, and prioritization can lead to quickly developed beta versions.
This article focuses on those who buy software development services. Learn about their points of view and what they need while planning a project (or when planning their own processes for information and communication technology projects).
Improvements in software development processes typically raise a lot of enthusiasm in software development organizations. Quite often, though, the customer's (buyer's) side of the equation is forgotten. The customer might be inexperienced as a buyer of software development services and isn't thinking about process issues. Forgetting to involve customers is a shame, because it can create a situation where the improvement efforts go awry. Especially if your organization is implementing agile methods, you should remember that the methods require a certain type of behavior from the customer. Without agile-wise customers (and agile-wise contracts), the adaptation of agile methods is not likely to work.
The foremost issue on a customer's mind is the business problem that the project is supposed to solve. The developer organization should always keep this in mind.
From the developer's point of view, there are two typical cases where the relationship between the customer and the development organization is likely to be difficult.
- Customer representative is not an experienced buyer of development services
- In this situation, the customer is often extremely price-sensitive,
and might not understand why requirements analysis, design, and
testing are necessary or how much time they usually take. The
customer might compare prices and timetables to shrink-wrapped or
configurable products. They typically ask for fixed-price offers and
don’t have written requirements.
From the developer’s view, this is a dangerous situation. To fulfill the contract, developers are forced (either by the customer, management, or deadlines) to write code instead of to design. This jeopardizes future projects, quality, and in the end, the reputation of the developer organization.
It is also dangerous for the customer for reasons discussed later in this article. If you’re the buyer in a company that does not have experience buying software development services, what can you do to improve matters? First, know the amount that your company has budgeted for development services for this project. Sometimes the budget is enough for configurable products but not for custom-developed software.
If the project is still in the planning phase, it might not be too late to change the scope and the goal. Always remember—and emphasize to other project members—the business problem your project is solving. Get some additional help if you need it by hiring an independent consultant with experience and good communication and reasoning skills. The consultant will know if your budget and plan don’t go hand-in-hand. The consultant will also go through your business case (the problem) and help you phrase it in a form that you can later use while selecting your developer.
- An experienced buyer of development services has a formal buying process
- This customer will either aim for large fixed-price projects, or for
long (between three to six months) contracts. If you’re willing to use
the customer’s development process, then this can be an ideal customer
for you. However, if you’re willing to use only agile methods, you
might face difficulties.
No matter which side of the table you are on, keep in mind that fixed-price deals and agile development don’t work together well (see Pricing). For people wanting to use agile methods, the real question is: how well do the customer’s processes support agile principles?
As you might have realized, a big factor is often the level of trust between the developer organization and the customer. If the customer doesn’t trust the developer to be effective and to do quality work, they are more likely to go for fixed-price deals, which will drive away agile developers.
This section takes a high-level look at the process of buying development services from the customer's viewpoint.
First, there is the business problem, which needs to be defined in a way that makes it easy to discuss. Some organizations use simple tools, such as e-mail or slides, while others have more formal methods for describing the problem. Depending on the problem and the closeness of the relationship between the customer and developer organization, the developers or outside consultants can help define the scope and requirements of the project. If an agile process is used, requirements can be at a high level of abstraction because they might change anyway before implementation. At this phase, the customer starts talking with one or more developer organizations in order to negotiate a deal.
If the business problem gets solved in a single project, then the customer doesn’t need to worry about defining the contents and requirements of the next project. However, quite often the development of custom software continues with new projects, iterations, versions, and so on. In this case, while developers are working on the current project, the customer must work on the contents of the next project. If the new project doesn’t continue right after the first, there's a danger that the development team will get assigned to another customer and they won't be available for a while.
It is wise to be open about the continuity and road map of projects, because that will allow the developer organization to plan their resources. It is also in their best interest to use the same developers for the new projects.
It is beneficial to understand the typical incentives that the buyers are looking for, and what is important to them. The first and most important issue is that the project offers a solution to the business problem. Without a clearly defined business problem and a calculated return on investment, the project does not have a clear scope and will likely be canceled later on.
The price is always important. The price is more than just the cost of the first project done by the developer organization. The price consists of development costs, testing costs, internal costs, server hosting, support, and maintainability costs as new features are developed. Quite often, buyers (especially inexperienced ones) compare only the initial development costs and forget the rest.
The development team is one of the most important factors in a buying decision. An inexperienced team costs less and is more likely to be available on short notice, but the level of experience of individual developers and the developer organization has a huge effect on the quality of the software. Great developers create good, maintainable software that is easy to support and further develop later. They might cost a little more, but they are certainly worth it.
The continuity of the development project is also important to acknowledge. If the first project is to be followed by another, and then another, the customer should be open with the developer organization and create road maps so developers can plan their other work. If every project is a separate project, preceded by a time-consuming tendering process (proposals, negotiations, and so on), the really good development teams will find other customers with whom they can build trust and lasting customer relationships.
There is also a nonspoken issue for the buyer that is rarely mentioned or even acknowledged. The person who is buying must win something on a personal level, or at least be very sure not to lose anything. This does not refer to money or anything illegal, but to issues such as reputation, career, or saving costs in a tough situation or problem project.
For developers using agile methods, the lesson is clear. If your customer is not agile-wise, you can try to do the convincing. But it might take longer than you think. Imagine it from the customer’s point of view: if their organization has no previous experience with agile methods, why would they risk the project?
There are practical ways to convince the new customers. You could, for example, invite them to a seminar you've arranged where your current customers explain the benefits they have experienced.
Pricing is one of the most important factors in making the decision to buy software development services. The pricing model has a huge impact on the quality and nature of the work. The following are brief descriptions of various pricing models.
- Fixed price
- One of the most typical pricing models. The customer provides a thorough requirement specification, and the developer organization makes a proposal for a fixed price. In this model, the requirements are the contract, and the use of agile methods is not likely to work well.
- Time and materials
- Another common pricing model. All work is invoiced for an hourly or
daily price. Some developers like it and some don’t. The ones who like
it aim for high utilization rates and high hourly rates. Those who
don’t like it criticize that added benefits and the responsibility for
the complete project are hard to tie in with the hourly price.
Customers feel similarly—some like it and others don’t.
This pricing model works well with agile methods because all work is invoiced as it is completed, and there can be as many sprints (and changes) as the customer wants.
- Combination
- A combination of the two previous models is sometimes used. The
requirement specification can be done with the time and materials,
since nobody is really capable of estimating how much work the
specification requires. After the requirement specification is ready,
it is much easier to estimate the work effort for design and
implementation.
Agile methods don’t work well with this pricing model because the requirement specification is a contract, and all negotiations must go through change management practices.
- Target price
- In target pricing, the customer and developer organization agree on a target price and all work is invoiced at an hourly rate. The developer organization aims for the target price. If the total is less than the target, the developer will get a bonus. If the price is more than the target, the difference is invoiced with a lower hourly rate.
- Cost-beneficial
- This is a less common pricing model. The developer organization
will get its share of the savings that the customer gets. It is very
effective, and the customer knows that the developer’s interest is
also the customer’s interest. The only potential problem is if
defining and measuring the saved costs is not simple. This pricing
model requires that the customer and developer organizations trust
each other. If the theoretical sum of costs saved is big enough, agile
methods can be used.
From the developer’s point of view, this pricing is quite close to the target pricing model. From the customer’s point of view it is safe, because they will save money no matter how well the project succeeds.
- Share-of-winnings
- Share-of-winnings is quite similar to the cost-beneficial pricing model, except that the developers get a part of the winnings. Like cost-beneficial, measuring and defining the winnings is important, and both parties should trust each other.
It’s always good to consider what the folks on the other side of the negotiating table are thinking. With software process improvement, the customer’s point of view is often forgotten, or the customer is not actively involved in the improvement process.
In this article you learned about the buying process from the customer’s point of view. The focus was on the customer's main incentives, and the pricing models and their effects on the project. You also learned which pricing models work well with agile development.
Learn
- Check out the other parts of this series
on adopting agile development:
- Part 1, "Is agile development right for your organization?" (developerWorks, Mar 2008)
- Part 2, "Understanding the different facets" (developerWorks, Apr 2008)
- Part 3, "The role of agile stakeholders " (developerWorks, May 2008)
- Part 4, "Using user stories to define project requirements" (developerWorks, Jun 2008)
- Part 5, "Applying user stories in a Web-based financial planning tool" (developerWorks, Jul 2008)
- Read Wikipedia's discussion of
user stories.
- Read more about
Scrum and
Adaptive Project Management Using Scrum.
- User Stories Applied: For Agile Software Development
by Mike Cohn explains how to develop flexible, practical requirements
that work; save time and develop better software that meets users' needs;
gather user stories—even when you can't talk to users; and leverage user
stories as part of planning, scheduling, estimating, and testing.
- For more about the business of software,
check out CMM in Practice: Processes for Executing Software Projects at
Infosys by Pankaj Jalote.
- Check
out
Business Models: A Strategic Management Approach by Allan Afuah to find out more
about business models.
- Get an
RSS
feed
for Mikko Kontio's Architectural Manifesto column.
- Browse the
technology
bookstore
for books on these and other technical topics.
- In the
Architecture area on developerWorks,
get the resources you need to advance your skills in the architecture
arena.
- Find resources to help you architect enterprise and software systems in
free IT architecture kits from IBM.
- Stay current with
developerWorks
technical events and webcasts.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from IBM® DB2®, Lotus®, Rational®,
Tivoli®, and WebSphere®.
Discuss
- Read what everyone is talking about in
developerWorks blogs
and get involved in the
developerWorks community.
- Check out Scott Ambler's
blog
- Strategies for Scaling Agile Software Development.
- Participate in the
IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
