For Startups: Effort Assumptions in Software Development Estimates?-? A Comprehensive Guide

Pre-Introduction

I was going for a full article about my estimate sheet, but that proved to be long, so I am breaking it into multiple small?ones.

This is a part of the “Building a Killer Professional Services Team ”?series, where I am sharing my experience in building teams, and startups.

Happy reading and drop comments if you have something to add, or something needs change. Thanks in advance.

Introduction

When going into new software development projects, whether during the pre-sales phase or just before development kicks off, the accuracy of your project estimates can greatly impact both the process and the outcome. A critical yet often overlooked component of these estimates is the assumptions made by the development/pre-sales team when estimating.

?Assumptions can turn a well-planned project into a challenging delivery if not clearly defined and managed. On the contrary, if it were a bullet-proof assumption, the delivery and testing phases would be extra smooth.?

A simple example will be the performance/responsivity of the website considering the expected number of concurrent users. A statement that we use always, but what is the definition of concurrent users, this will prove a challenge later to the testing team and the development team later, and might cause friction when closing the project. When developing, the dev team will say it is 500 users per 1 minute, and the response time is 1 sec. While the client was expecting a smaller interval, 500 seconds. That will definitely make things blow up.        

Based on my experience, today we’ll go through the common assumptions made during chatbot and website development projects.

Here are the assumptions we will be talking about:

• Workflow Assumptions
• Integration Assumptions
• Website Assumptions
• Chatbot Assumptions
• Feedback Loop

If you are interested in the training assumptions?—?if your company is delivering training at the end of the delivery, requirement gathering assumptions?—?for example, to have the same stakeholders in all sessions, project management assumptions, etc.

Workflow Effort Assumptions

A common pitfall is when you propose delivering a workflow and don’t define how many. You should go with something like this:

Workflows Assumptions:
- 5 small workflows 
- 3 medium workflows 
- 1 complex workflows        

That looks better than not specifying it, but your perspective is different from your client's and your sales team's. I would leave that in the proposed solution but then complement it with something like the below in the assumptions:

Workflow Assumptions: 
- Small Workflow Definition: 3 Forms, 5 fields in the main form, 2 fields for decision making in each of the other forms, the decision maker can return it back, 3 roles?—?one per each page including the requester.

- Medium Workflow Definition: 5 Forms, 10 fields in the main form, 3 fields for decision making in each of the other forms, the decision maker can return it back, form can be delegated, form can be escalated, 5 roles?—?one per each page including the requester, 3 get integration.

- Complex Workflow Definition:?….. Bla bla bla 

- [This one is usually forgotten] Other Workflows are not covered in this proposal and should be addressed in details in a 1-on-1 session.        

Then, on your side, you would have those definitions and estimates already defined by the technology team. For example, an estimate for Nintex for the above will be different than Zapier, different from a custom workflow builder, etc.

So, bottom line, you will have a pool of estimates for your pre-sales team that can pull from, along with its definition and technology.

Better estimates, fewer interruptions for your dev team, and more independence for your pre-sales team.

Note: Will discuss the below in another article. If you are interested, leave me a comment to prioritise it over other articles.

Of course, there is a margin for error in your estimates, usually 30% if you are not following the above, but if you do follow it, the error margin can go down (I believe) to 7%~10% depending on what you are delivering, the smaller the delivery, the bigger the buffer.

Integration Effort Assumptions

Yes, I am trying to hit the nail on the head, I have been there?—?multiple times?:)?

Another common pitfall, is integration assumptions, usually we believe that an integration will be as easy as calling an API and retrieving information, easy peasy. But here is what I learned!! [The hard way?:’(]

Integrations Assumptions:

- A total of 2 simple integrations?—?other than the mentioned below will be delivered
- Integration with XYZ OAuth provider for authentication
- Integration with system ABC to pull the user's data
- Integration with BI system GHI to push the usage data        

But there is so much that can go wrong when integrating, including the scope, performance, etc.

Integrations Assumptions:
- Simple Integration Definition is: An API request in JSON format, authenticated with a PAT or a Bearer Token that doesn’t expire, syncing 10 fields max. 
- Integration with XYZ will follow protocol 123, and will abide to the 123 standards documented here: https://123-standard.com 
- Integration with ABC, will be a GET request for fields 1, 2 and 3 in JSON format following the industry standards? 
- Integration with BI system GHI v13.4.6.89, and we will be pushing fields 1, 2 and 3 in JSON format through a POST request. 
- It is assumed that all the above integrations are well documented as per the industry best practices, and that the documentation will be provided at the beginning of the project. 
- It is assumed that all the above integrations will be delivered in the expected timelines as per the project plan attached and as per notified/requested by the Project Manager. 
- It is assumed that all the above integrations are accessible through our company’s premises, and if not, it is expected to be allowed through your firewalls following any security measures requested by your security team. 
- It is assumed that all the above integrations are up and running with high reliability. 
- It is assumed that all the above integrations will respond with a timely mannered not more than 10 seconds for non
-production environment, and 1 second for production environment. 
- In case any of the above assumptions doesn’t meet your expectations or capabilities, please notify us.? 
- In case the APIs are not yet available, we are expecting reliable mockups with minimum changes over time.        

Again, on your side, have the estimates ready per technology for each of the definitions. For example, in one of my previous projects, we had an integration between two systems, one was ORACLE SOA and at that point it was working with XML only, and the other was a blockchain product that expects JSON, we had to build a middle layer to do the transformation.

Things like this should be covered in the Risks, with a contingency and a percentage of effort.

Note: Will discuss the above in another article. If you are interested, leave me a comment to prioritise it over other articles.

Website Effort Assumptions

Website projects often carry their own set of assumptions, particularly around performance and user experience. Developers and clients must agree on specific technical and performance metrics.

There are tons of assumptions that should be added here; I will do my best, though?:)?

Web Interface & Performance Assumptions: 
- We will support Accessibility level 2 as per standard WACG 2.0, you can find more about it here: https://accessibility.com, and we will not support points 3.5 and 3.6 as the product doesn’t support the needed features to develop it. 
- It is assumed that peak times, the concurrent number of users for an interval of 1 minutes is 500 users, and that will be during the normal working hours 9 AM to 5 PM EST. 
- It is assumed that the non-peak times will hold a concurrent number of users of less than 100 for an interval of 1 minutes, and that will be during the rest of the day. 
- The homepage will be fully rendered in 2 seconds in normal times, and 5 seconds in peak times, and that in case of applying option 1 in the infrastructure section. Or 1 seconds in normal times, and 2.75 seconds in peak times in peak times in case of applying option 2 in the infrastructure section. 
- The website will support 2 languages only, language 1 and language 2.?
- The website will support responsive design, and will be tested against resolutions 1920×1080, 1366×768, 1280×1024 for desktops. And mobile devices 1, 2 and 3. And browser Chrome, Safari and Edge.        

In proposals, I have learned to include, let’s say, two graphic design concepts for the homepage that are fully ready to be approved. I also allow the user to choose one, adding assumptions about how many changes are allowed on the design. This makes changes much less later during the development phase, as the user already saw what we would deliver and we had already met their expectations. It is a double-edged weapon, but it makes things move faster and sets expectations.

Chatbot Effort Assumptions

Like websites, chatbots also have their assumptions; some are common with websites, like accessibility, and some are not, like things related to conversation design.

The chatbot workflows can have assumptions similar to those in the workflow assumptions section, and the same for chatbot integrations; they should have something similar to the integrations assumptions sections.

Chatbot Assumptions: 
- It is assumed that the training data are well structured and well labeled 
- It is assumed that we will use the B platform features without changing any features. 
- We will support Accessibility level 2 as per standard WACG 2.0, you can find more about it here: https://accessibility.com, and we will not support points 3.5 and 3.6 as the product doesn’t support the needed features to develop it. 
- It is assumed that peak times, the concurrent number of users for an interval of 1 minutes is 500 users, and that will be during the normal working hours 9 AM to 5 PM EST. 
- It is assumed that the non-peak times will hold a concurrent number of users of less than 100 for an interval of 1 minutes, and that will be during the rest of the day. 
- The chatbot will support 2 languages only, language 1 and language 2.? 
- The chatbot widget will support responsive design, and will be tested against resolutions 1920×1080, 1366×768, 1280×1024 for desktops. And mobile devices 1, 2 and 3. And browser Chrome, Safari and Edge.        

Feedback Loop

At the end of the day, the above is just something from my previous experience, but you must have a repo tailored to the company, its needs, its strategy, etc.

And there should be a policy in the company that at the end of each project while doing the “Lessons Learned” session (As per PRINCE 2F), part of that feedback should go back to your Assumptions Repo.

For example, we did a big mistake, related to sockets in one project, we assumed that the way of developing sockets is the same the client is expecting, and that it will be an easy task to deliver?—?but it was not, and it dragged the project for an extra 1 month at least.

You should add an assumptions sheet/tab to ensure it is noticed in your estimate sheet. Below is my example estimate sheet, which I am still enhancing; if you have comments, please drop it and help me?:)?

Standard_Efforts_Sheet-V2.0.xlsx How To Use Still work in progress You can leave a comment We can collaborate if you want docs.google.com

Conclusion

In software development, articulated and managed assumptions are key to aligning expectations and ensuring project success. By systematically addressing chatbot and website development assumptions, teams can avoid common pitfalls and align more closely with client expectations. Review your estimation processes today; consider how a sharper focus on assumptions could refine your approach and lead to better outcomes.

References

• It is all personal experience between the different projects I worked on, managed, and delivered. From Chatbots to websites, to integrations?.. you name it?:)

Thanks for Reading?and…

If you’re also on this startup journey, figuring out the ropes as you go, I hope this series helps clarify these essential tools. And if there’s anything you think I’ve missed or gotten slightly off track, drop a comment. Let’s keep the learning going!

How Can I help?you:

1. Looking for a free mentor session ?
2. Was it worth a cup of coffee ?
3. Was it too good? Worth a Subscription ?