What could possibly go wrong?

Even though we begin every project with the best of intentions, it’s been our experience that there are many things that can go wrong. These challenges can affect the timeline, budget, scope and quality of the project and can be disappointing for developers and clients. As part of setting expectations for working together, we’d like to openly share some of the possible problems that can arise on a project along with information about what effect they may have and how we plan to address them.

• The project loses a developer. This can happen for all kinds of reasons. Someone gets sick or has a family emergency. A developer decides to move and leaves the company. It’s likely that this will affect the project timeline because it can take time to find a replacement developer and to get them fully integrated into the project. We address this by maintaining a talent pipeline of developers with various skills, but it still can take time to get a new person up to speed on the project.
• The project has an unexpected technical challenge. Sometimes this happens because of a misunderstanding between the developer and the client about how a feature should work. Other times it happens because of a problem with a system over which we have limited control, such as a 3rd party integration. Sometimes a feature seems fairly simple or straightforward, but once we start working on it, some problems arise and it turns out to be far more complex than it seemed. It’s likely that this will affect the project timeline and budget. Sometimes a story that was estimated at 2 hours could end up taking 20 hours or more to complete. We will discuss it with you if we find that a feature is taking much longer than expected. In some cases, we can agree on a simpler way of doing things that might save time. You may decide that the feature is simply not worth the extra effort and choose to eliminate it from the project. Or you might decide that the feature is important and that the extra effort, time and money is worthwhile.
• The project scope changes. Since we have an agile development process, we expect that the project scope will change. It’s impossible for most people to imagine every feature they want or need before they actually start working with the software. Inevitably, the client or developer will think of new features or additions or changes to existing features once the project is already underway. Project changes will often affect the timeline and budget, but they can be managed for projects with a set budget cap. We use a process called CAPE to manage scope changes. A client can Choose to Approve the change and expand the project budget, Postpone the change to a later phase of the project or Exchange the new feature for an existing feature of the same point value to keep the budget the same. (Point value refers to the estimated effort for a particular feature.) CAPE can be used to manage changes to existing features as well as new features.
• A feature takes longer than expected. For any feature, there are many different ways to approach the development process and achieve the desired functionality. There are often several simple approaches available and many more complex approaches as well. Depending on the preferences of the client and the developer, a simple approach may be fine or a more complex approach may be required. Note that the client may have the more complex approach in mind, but the developer might have had a simpler approach in mind when estimating, so there can be misunderstandings about a feature that cause it to take longer when we actually do the implementation. Approaching a feature with a level of customization and complexity that satisfies the client and the developer may sometimes take longer and cost more than what was estimated. We will do our best to communicate with the client about why and how we’re approaching a feature a certain way. In cases where the client’s expectations for each feature are very high, the client should expect to pay more for those features because they will take more time to implement. If the budget is limited, the client and developer should work together to find simpler approaches to certain features or limit the number of features if each one requires a more in depth approach. Note that we will review the level of customization needs for the project in more depth during our discovery process.

How does our billing work?

All projects are billed at our standard hourly rate and we bill for our time on the project in 15 minute increments. Retainer options are also available. We send invoices twice a month and all invoices are Net 30. We charge interest and late fees on overdue payments and reserve the right to stop work on a project if the payments are overdue. We send a detailed breakdown of our hourly work with each invoice for hourly projects.

We can accommodate hourly projects with a budget cap. The expectations around the scope for those projects will be set during a discovery phase by setting a fixed point value for the project.

• We bill for time spent doing development and design work on the project.
• We bill for time spent communicating and meeting with the client about the project.
• We bill for time spent orienting and training clients. When new client contacts come onto the project, additional orientation time may be needed and this will be billable work.
• If there are expenses on the project that we are paying for, such as a subscription, hosting or special software that’s needed, we will bill you for those items. We will give you advance notice of the costs and you will have a chance to approve the expense.
• We bill for time spent fixing bugs. All software has bugs. It would be prohibitively expensive in most cases to try to build software that is completely bug free, because you would need to do a huge amount of predictive work anticipating all possible bugs and then very extensive testing to identify all of the ones you couldn’t predict. All of these processes take lots of time and money. Most of our clients find it to be most cost effective to pay to have the software built and then pay for the bug fixes as they come up. We will, of course, use best practices in automated testing on the projects wherever possible and when the budget allows.
• We bill for time spent gathering requirements, estimating and doing planning and strategy for the project. All of these tasks take significant developer time and are an essential part of any web software project.
• We bill for project management time.
• If travel is required for a project, then we bill for travel time, travel expenses, meal expenses and time working on the project during the trip. We do not bill for leisure time, time at non-working meals or sleeping time on the trip.

We do not bill hourly for the following items:

• Customer service
• Social meals with clients
• Sales activities such as contract work
• Billing related activities, such as invoicing and bookkeeping

How will the project be managed?

As a complement to our agile development style, Singlebrook uses a project management tool called Pivotal Tracker for transparent collaboration with our clients.

Pivotal Tracker allows you to track the project anytime, anywhere. See what stories are in progress, which are complete, and which ones have not yet been started. Your development team can estimate work in a collaborative environment. Work you’d like us to start can be approved by simply dragging estimated work from the icebox into the backlog. Note that dragging work to the backlog is considered a written approval process, and you are committing to pay for this work once you approve for us to work on it. Work can be prioritized, reviewed, and accepted, all within one simple to use interface.

Upon request, Singlebrook will provide a free orientation to Tracker at the onset of the project.

Note that using Tracker results in the most efficient communication. Clients that choose not to use Tracker and do approvals and collaborate on feature work through other communication methods will get billed for the extra time required for translating these other methods into Tracker.

By initialing this document, I acknowledge that:

• I understand the project management flow that Singlebrook utilizes.
• I understand the CAPE process.
• I understand Singlebrook’s billing practices.
• I have been through or have been scheduled for Singlebrook new client orientation.
• I will utilize Pivotal Tracker to the best of my ability and direct any questions about its usage to my lead developer or another Singlebrook staff member.

I reviewed and understood this document.

Client Initials:

Date: