At BraveGeeks, we do custom software development. It’s been said that project-management standards are lower for custom development than they are for product development by “in-house” teams. We disagree.

Transparency requirements for project management processes for custom development are even higher than for in-house teams. The customer’s internal standards don’t apply to us, and it’s easy for them to stop requesting our services. Have you ever heard of a company’s internal team being fired for one failed release? That happens all too often to custom software development companies.

Custom development has three important peculiarities:

• the company requesting the software always wants to know how much the project will cost before you start
• projects are impossible to evaluate accurately due to a lack of information
• the work itself will definitely change throughout the process

Teams find themselves in situations where they are forced to evaluate projects but can’t do so with a high degree of accuracy. They also have to take into account the fact that the scope will definitely change.

If it weren’t for the need to provide a preliminary evaluation of the project, it would be possible to use classic Scrum. But there’s no such thing as a customer who likes hearing, “We’re going to work on development for a few months, evaluate velocity, and then let you know approximately how long the rest of the work will take.”

I want to tell you about how we work in this difficult scenario and how it’s reflected in our project management system (we use Targetprocess).

Basic principles

When developing the project management process for BraveGeeks, we defined three important features, which may seem mutually exclusive (although they’re not):

• we preach an Agile approach in development;
• we’re guided by the principle of “fix time & money, flex scope” (by 37 signals);
• we work according to the T&M model;

This means that we are receptive to customers’ requests to change the scope. We fix deadlines and budget ourselves, but we accept payment on an hourly basis. How does this work?

Understanding the task

First, we familiarize ourselves with the project in order to get a good understanding of what we have to do. At this point, it’s important for the team to understand the following:

• what product does the customer want to release, and why?
• who will use the product, and how will it make a profit?
• how will the business built around this product work?
• how will marketing and sales work?

Understanding the answers to these questions is important for more than just accurately evaluating the project. The team needs to understand their task so they can help the client create the first version of their product in such a way that it can test as many product hypotheses as possible.

A good understanding of the task also helps the team offer the best solutions for changing the scope when something goes wrong, so no one accidentally drops a feature that is critical to the business.

Project planning

Once we have a good understanding of the project’s overarching task, we help the client create a first version of the product, or minimum viable product (MVP), and give a rough evaluation in man-hours and money. We agree with the customer on the price per hour for team members, and we tell the customer how the work will be carried out.

This lets us fix the deadline and budget of this version, but we agree ahead of time that if something goes wrong (which will inevitably happen) we will change the scope without touching the deadlines or budget. The evaluation should still be realistic (you can’t release a bike instead of a car) but this is how we get some flexibility.

When all the documents have been signed, we create a project and attach to it all the documents we have at this point: project interview notes, a list of use cases, MVP definition notes, initial project estimation, and a milestones plan.

Based on the evaluation we gave initially, we create Features, saving the original estimate as the Initial Estimate. In Feature descriptions, we use clear business terminology and focus on a specific feature’s value for the business.

Then we agree on milestones with the customer. We create them as Releases and place Features in the releases. In so doing, we have a record in the project management system of the things we initially agreed on.

Iteration Planning

At the iteration planning stage, we begin using a classic Scrum approach. We use a calendar to plan iterations in a release, establishing a result for each iteration that has business value and is clear to us and the customer. For example, in the first iteration we implement the creation of materials and uploading of photos, but determining the location and saving it on the server is done in the next iteration.

The development team decomposes features into User Stories, discusses them with the customer, evaluates them, prioritizes them, and includes them in a sprint. The tasks included in a sprint no longer change.

However, features in releases may change, and there could be additional User Stories in a feature. The only limitation to these changes is our initial agreement: release deadline and budget.

This is fairly easy to track, since summary data about the initial evaluation and time spent per release and feature is automatically collected.

Kanban and time tracking

During each iteration, the team works with a classic project Kanban board. We place tasks on the board and make connections between them, taking note of their status.

The Kanban board lets us see the status of the current iteration: which tasks are stuck, which team members are overworked, and who has finished their work and is bored.

The main purpose of this board is to provide transparency into our process and signal problems.

We ask the team to track the time spent at the end of each day, dividing the hours among their different tasks. Thus, we see the total time spent on tasks and features, and we can take steps in a timely manner.

We use reports with charts to track the correlation between the initial evaluation of a feature and the time spent on tasks related to it:

Reports

At the beginning of each iteration, we send out a document with the iteration plan and evaluations, and at the end of each iteration we conduct a demo of what has been done and provide a report.

In the report, we indicate which task or bug we worked on, what feature it’s part of, and how much time each team member spent on it.

We use an API to get these reports from Targetprocess into Google Sheets. Based on these reports, we issue invoices to our customers.

Bugs

Bugs are inevitable in projects. Bugs are more than just concrete errors in the code — they’re all of the situations when the product doesn’t work how the client or user needs it to.

QA engineers usually identify bugs, and Project Managers prioritize them, discussing with the client as necessary. In each iteration, we devote about 20–25% of our time to fixing errors. This includes more than just bugs at the feature level; it also includes unexpected things like problems in testbeds, bugs in Continuous Integration scripts, and more.

We try to account for time spent correcting errors when first evaluating a project, but we can’t predict everything that will go wrong. For this reason, bugs are often what necessitates changing the contents of a release.

Changing the Scope

As soon as we realize that there’s a risk of missing a deadline, we begin a discussion with the client about which feature to remove or simplify in order to have the release on time. At this point, we usually have a good idea of which changes will free up significant time and which won’t. In turn, the client has a good idea of the importance of the product’s function for the business.

Changing the scope is a very painful process for both the client and our team. But at the same time, it’s inevitable. It’s important to understand that you can’t keep changing the scope endlessly, or else the product will be a total loss.

Conclusion

Although it isn’t perfect Agile/Scrum, we believe that our approach allows us to release products on time and within budget, without sacrificing the quality of the final product. The idea is to release a product with a smaller number of features, which are created well.

The approach guarantees transparency into processes and gives us flexibility when responding to customers’ change requests. We hope that this was a useful read for you, and we would love to hear your thoughts.