The following article is a guest post written by Tim Gursky.
A quote is probably the most important piece of any project, both for the client and vendor. The estimate, when performed correctly, will deepen the understanding of the scope of project, as well as provide ground for deadlines, milestones, and resource allocation. An estimate is the bedrock of trust that is established between a client and a vendor, and allows planning of expenses and revenue.
This article discusses some techniques and processes that are not directly involved in the estimation process, but can build a solid foundation for it. We will publish more detailed articles on these items later, but for now, I would like to simply introduce the techniques and briefly describe them.
Organizing the Requirements
The key to a quality estimate lies in a deep and thorough understanding of the problem. So, before any work on the estimate itself commences, the team needs to gather and organize the requirements for the project. Once the foundation has been prepared, working on the quote is a breeze. We believe that discovery of the challenges that the client is experiencing is part of the business acquisition process and allows us to not only estimate more accurately, but also exercise our creativity in brainstorming solutions.
Requirements Workshop
This stage introduces the upcoming project to the vendor for the first time. Therefore, it doesn’t have to be too detailed in nature. The most important aspects of the problem are revealed at this stage. These can be discussed in a meeting, on the phone, or via electronic communication. We prefer to have the client fill out our questionnaire and visit the office with their answers in hand. Bringing in designers, developers, and business managers into one room results in great ideas and an expanded specification document.
Use cases
Once preliminary requirements have been gathered, the analyst needs to process them in order to organize them and develop missing pieces. Use cases help document functional requirements in the form of stick figures and arrows representing interactions with the system. The system itself is treated as a black box in this case. Its internal processes are not important at this point. This method captures functional requirements only. For example, a Use case may document the process of adding a product to the cart and placing an order (without going into the details of how and where the order is stored and how the funds are routed through the system).
Entities
Based on the use case diagrams, an Entity Relationship Diagram (ERD) is created. At this point it’s a conceptual diagram (i.e. it doesn’t have to mention any data types, or any other implementation-specific details) that represents a general, yet important, idea of what objects in the project will have what relations. The essential information in an ERD should contain is all planned entities.
Mind maps
A mind map is a graphical representation of information and ideas around a single term (concept, project, etc.). Major categories of items are attached to the main node, and then each of the categories is itemized until the diagram contains all important information in the shape of a giant spider. It’s important to find a balance between the level of details and the simplicity of the graph, as too-detailed structures lose clarity and become less graphic.
Mind maps are extremely helpful in gathering important requirements from different sources, like RFP, use-cases, ERDs, email strings, phone calls and meetings, task management services, and so on. This approach captures both functional (processes) and non-functional (usability) requirements.
An example of a mind map for a simple shopping cart project is below:
A good mind map editor is XMind (http://xmind.net, free and cross platform).
Estimating
Once the requirement documents are ready, the analyst can move on to the estimate itself. The proper way to build an estimate is to split the scope of work into categories and let representatives of each department work on their own parts of the estimate. For example, wireframing and design portions are estimated by the design team, prototyping–by a front-end developer, development–by an architect. The volume of work within each category is broken down into individual tasks. The single scope of work, supported by initial documents with requirements, keeps everyone on the team on the same page. This helps minimize discrepancies in the final document. The analyst reviews the final estimate and adds time needed for QA, project management, and other supporting activities.
It’s important to not estimate for the sake of estimating, so a few “shortcuts” are used:
1. Experience-based estimation
Most web sites/applications use similar components (login and signup forms, user management, mailing, storage and image processing services, etc.), which allows the analyst to reuse estimations for certain tasks from past projects. It’s important, however, to compare actual vs. estimated effort at the end of the project to make sure the evaluation is accurate and can be reused again in future projects.
2. Rounded amounts of effort per task
An estimate shouldn’t contain any 15 or 30-minute intervals. It’s an evaluation, and it can’t be that precise. Guesstimating such small time spans will result in hours spent in the elaboration phase of the project without much benefit. In some cases (for example, when using Agile), numbering matches a certain set or pattern (using user points will result in numbers like 1, 2, 4, 8, and so on). This method decreases the chance of inaccuracy in an estimate since the estimate itself isn’t meant to be accurate down to the minute or half hour. For example, Microsoft uses half-days and days in its evaluation process.
3. Fixed percentage for QA and project management
Some evaluations can be established empirically. For example, project management usually takes 10-20% of the estimate subtotal, depending on the intensity of communication between the client and the vendor.
4. Capped hour buckets
If a task effort estimate comes close to large numbers (like 16, 20, or 24 hours for bigger projects), in most cases it’s beneficial to break it down into smaller pieces to make sure nothing has been left out or misunderstood.
5. Evaluation refining
Some features can be estimated by adding layers of complexity to a base feature. For example, the client needs a contact us form on the site, which sends emails to the site admins. Let’s say this feature usually takes six hours to implement. Another requirement is to let the user pick the department to receive the message – it adds another two hours to add a drop-down and sending of the value. Another two hours will be spent on extending the database, adding data entities, and populating lookup data. If the client wants the messages to be saved to the database, it will be an additional two hours. Another four hours will be spent on adding an appropriate section under the site’s admin panel and listing the messages there. This comes to a total of 16 hours to implement this feature.
An important rule that usually gets omitted in order to please or impress the client is that the estimate should never be based on an optimistic scenario. Not a single project goes 100% according to plan because software engineering is an evolutionary process, so having such an assumption in mind while estimating effort is a really bad idea. Instead, try to predict an average, slightly bumpy, project roadmap. This always works better, as your client will have an idea of the final cost of the project, and you will know the amount of resources you need to allocate to the project.
Wireframing
Since the estimate features a realistic evaluation of the project effort, and the documentation available isn’t enough to define the scope 100% precisely, the outcome of the quote can’t be a set number of hours/amount of money. Rather, a good estimate results in a range, featuring the most likely optimistic and most likely pessimistic scenarios as its boundaries.
Depending on the complexity of the project and the level of details in the requirements, the initial quote usually has a 25-50% ROM (rough order of magnitude) variance. Yes, it’s quite a wide range (assuming a project can cost anywhere from $100-300k in the case of a 50% variance), but it reflects how well project requirements are defined and how many unknowns there will be in the system (e.g. integrations with third-party services). There are numerous ways of implementing a shopping cart, for instance, or a user management section in the admin panel.
A good technique that can help define the scope without a full commitment to the project is wireframing. Once the initial estimate is ready, the vendor proceeds to the wireframing stage. Because graphic representation of the scope is really detailed, and can be interpreted by all teams working on the project, it lets the analyst re-evaluate the estimate if needed and decrease the variance up to 15-25%. The percentage might be different depending of the number of well-defined and known components in the system (integrations with third-party systems, component reusage, etc.) The produced wireframes can be used as a foundation for the functional specification.
Changes to the scope
Wireframing allows the vendor to address changes requested by the client at a very early stage in the project. As a result, the number of scope changes during other stages of project implementation is decreased. Change requests are inevitable, and should be estimated and tracked separately. At the end of the project all of these evaluations are added to the upper boundary of the estimate.
Estimating right can build trust
This process isn’t a silver bullet of estimation, and it can be adjusted to meet particularities of a given company. However, it has allowed Devbridge to significantly increase the number of projects that stayed within budget, and it has led to establishing trust with clients, better resource allocation, and a more predictable load and revenue stream.