Posts

It was the summer of 2001, when I walked into the office of a small student recruitment agency. They were in the business of finding exceptionally talented students for part-time jobs working in the IT industry.

For students, it meant bringing their knowledge into practice, while for the companies it was both an opportunity to get work done at a low price, as well as a recruitment channel. But I was there for a different reason.

The breakdown

The recruitment agency had asked me to custom build their website. Nowadays you wouldn’t build your own CMS, but in the early days of the internet, this was more common. So, there I was, ready to talk requirements on a hot summer day, in the souterrain of a canal house in Amsterdam.

Across the table from me was one of the owners of the agency. They explained in detail what the goal of the site was, which functionality he wanted and how things should look. We made a few changes to the sketches he had already made, and I was good to go.

To give an accurate quote, I broke down the work into smaller pieces. Designing the database, writing code to retrieve and store data, and code to handle the functionality. Finally, writing HTML and CSS to make sure the site would look nice in all browsers.

I then estimated each piece separately, making sure no single estimation was higher than 1 day of work. If that was the case, I would break it down into smaller pieces. Grand total: about 10 days.

Doing the work

With the estimation and the work in hand, I started coding. I already had considerable experience at the time, since I was used to doing a lot of similar coding, so I was confident in my estimations. As I was coding, I continuously checked how much time I had for each piece. This forced me to work quickly and effectively.

After I had finished coding and testing I had spent exactly 4 hours less than I had estimated. The site was now ready to be tested by the agency.

Big surprise

When I entered the office of the recruitment agency again, the owner was already there. He had tested the site and, apart from a few minor pointers, it was completely to his liking. Then he told me that he didn’t expect me to finish this quickly. He had actually anticipated the project to take 1.5 to 2 times longer!

I was perplexed, I had given him a very detailed quote, which he’d accepted and he expected me to take longer than I told him? What did he know about how fast I can work!? So I decided to ask him why he thought I would take so much longer.

In his experience, he had never had a project done in the estimated time. It usually took at least 1.5 times longer than projected, which is why he had already factored in this number. He then told me that he did the same towards clients. A student would give him a quote, he would double it, and present that to his customer.

It all seemed strange to me, these were people that were good at what they did, had some experience with it, yet couldn’t estimate a simple project correctly… I didn’t give it much more thought then; my customer was happy and I was happy having done a good job.

Estimating is key

Years later, I encountered similar situations in software projects where I wasn’t the one making the quote. It only then occurred to me that there was something that most quotes have in common, which leads to the estimation being incorrect.

Where I had broken down all my work into neat little pieces that were easy to estimate, this is not always possible. There are several reasons why this is the case. The most common one is that not all requirements are known when the quote is requested, making it very hard to give an accurate quote. Estimating for uncertainty is something that is bound to be inaccurate.

Another reason is that usually the work isn’t broken down into smaller pieces that are each estimated separately. Rather, the project is estimated as a whole, or in big chunks of work. Humans are notoriously bad at estimating, which means that the larger the chunks are, the bigger the difference between the quote and the actual effort will be.

The final reason is the most important one. You have requested a quote. But you have not requested a single quote. Usually, you request multiple quotes. And the most important decision factor is price. This means that companies will often leverage the fact they don’t know all requirements. They will estimate everything that is known, but leave all other points open. This will of course be ironclad in the fine print.

Getting good quotes

To get a good quote, it is very important to have someone who can judge the details of the quote. And I don’t mean the financials, that’s the easy part. It’s about the technical details. You will need to involve one of your team members who can identify what has been left out, even if it’s not specified.

The most overlooked aspects are usually security and testing. Testing should simply be part of the quote, as well as fixing any issues that emerge from testing. Security is a very costly aspect if not done right. And getting it right, is hard. So, make sure to get a security expert involved in all of your software projects, as early as possible.

And the last thing you can do, is to ask for a fixed price for the entire project. This can identify the points of the quote that have intentionally be left open. Because when the company knows they cannot charge you more if it costs more time, it is suddenly in their best interest (instead of yours) to get the quote right.

In my other blog, I told you about the need to acknowledge your boundaries before pushing them. Being new to the world of IT, I’ve experienced that it’s better to tell coworkers when you require more time or help.

A platform like Triggre is created to be used by everyone, so if you’re willing to learn, you’ll figure it out. In this blog, I’d like to elaborate on that.

Finding answers to questions: what’s the right approach?

Learning step by step is key. Admittedly, this is easier for some than others. But if you show your coworkers that you want to learn from them, they will understand and help you. Everyone has their own field of expertise.

Sit down with an IT expert to talk about the difficult technical things, ask a superior for feedback on your work or attend a meeting with a sales representative. If you do this from time to time, you will book progress quicker than you think. On the other hand, you should tread carefully to find the right balance when asking questions.

Let me tell you briefly about a company that I used to work for. In the customer service department, people were answering questions of customers all day long.

New employees didn’t have most answers right at hand, so the company had set up a large database containing common questions and answers. The database was easy to use and provided the right answers quickly.

However, some employees skipped the independent searching part and constantly interrupted their coworkers to ask for the right answers. Others couldn’t bring themselves to admit they didn’t know something, so they just guessed, which often resulted in the provision of dramatically wrong information.

My point is that if you have resources available that will help you and get you further without having to bother coworkers, always use them first. This way, you show everyone that you’re actively trying to learn and can work independently.

If you still don’t know the answer afterwards, don’t fret and ask your coworkers! If you show a good personal work ethic, no one will refuse to help you.

How about Triggre?

Triggre is made for people who don’t possess any technical knowledge. However, it is important to realize that no tool is a magical box that will work if you are not open to learning new things.

Triggre is a toolkit that you (and everyone else) can use if you are able to gain the right skills – which is by no means difficult. It only requires a healthy dose of inquisitiveness!

My first job in the IT-world started a few months ago. It is intense to start something completely new after just graduating, since finding your way in a new industry takes a lot of time and energy.

I learned more things in a few months at Triggre than I was used to from school. That can either be the best or the worst experience – depending on how you deal with it.

Recently, I had my first face-to-face meeting with a client looking for software solutions. He was an employee in his mid-fifties who told us that he was solely responsible for implementing automatization in the company.

He had to look like the go-to person for the job, but I quickly noticed that he had second-to-no experience regarding software creation – and I recognized his situation immediately.

He was dealing with a subject that he was supposed to know every little thing about. But learning software takes time and he just wasn’t ready yet, which made him super uncomfortable.

First steps in the world of IT

The meeting made me reflect on the issue of being new to the ‘software business.’ I have a marketing background, which I can apply to a variety of situations, but this is my first IT-related job. I’ve quickly come to understand that it’s a world with laws and rules of its own, and you need to familiarize yourself with it.

It doesn’t matter if you’re a fresh graduate or a seasoned professional with decades of work experience. It’s important to accept the fact that there are certain things you are not capable of doing yet.

However, many people find it difficult to admit that. This can result in distressing predicaments, because they feel forced to accept projects they simply cannot handle. In the end, no one will benefit from a non-transparent attitude.

Ultimately, you’re creating a very non-pleasant work situation for yourself in which you are constantly frustrated and under pressure.

Solution: acknowledge and learn!

So what is a constructive solution? In my opinion, the key is to embrace your lack of knowledge as well as the drive to learn.

Platforms like Triggre are made to be used by everyone, so if you’re willing to learn, you will figure it out.

And if you need more help, just ask. I’ve experienced that it’s better to tell co-workers you require more time or help, since you show them you’re willing to learn and acquire the right skills. In my next blog, I will elaborate on this solution in more detail!

“This software product already does 90% of what we need.” If only I got a cent every time I have heard this. It is the most ridiculous argument there is for standard software versus custom built software. When companies or teams select software, it is a common mistake to look at the percentage of functionality covered. Doesn’t a 90% coverage mean it’s just a small step to get exactly what you want!?

Adding a floor

Consider a high rise. 50 floors of exquisite architecture, exactly in the right location. And it’s super affordable. If only it had 2 extra floors…

The solution might be simple. If you need 2 floors added on top, that might be a viable option. Perhaps the elevator won’t reach them, but it wouldn’t be extremely expensive to do.

It’s a slightly different story when you need a double basement underneath the building. It’s still possible, but far more expensive.

The ultimate case however, is if you absolutely need to add two floors at the bottom or in the middle of the building. I am sure it can be done somehow, but I bet it’s cheaper to build a new building.

Adding a software floor

All three cases with the building add 10%, but it seems obvious that they are not equal. In software however, we somehow assume they are equal.

So whenever you consider ‘adding a floor’ to standard software, make sure you fully understand exactly what the impact is. No matter how configurable the software is, how many happy customers there are that ‘do things in the same way for 90%’ – if you try to add the wrong floor, it’s going to cost you.

The last time I went skiing was about 20 years ago. Skis were a lot different back then, than they are now. You had to have skis that were at least as long as you are tall.

And if you were a good skier, you would have skis that were way longer than you are tall yourself. So, you can imagine my surprise when I went skiing again after many years? A lot has changed.

Hardware has changed

There are many differences between the hardware I used 20 years ago, and the hardware used today. Skis used to be longer and straight while today skis are curved and much shorter. These changes in hardware offer more possibilities.

When I first learned how to ski, the epitome of what you could achieve was called ‘wedeln’: making short parallel turns. With today’s hardware this is still possible, however, more options are available such as carving for example.

There are even more types of skis, specific to the desired technique, from race carve to off piste skiing.

Adjusting to the new

Ultimately it comes down to the skier, who has to adjust to these new possibilities. The new techniques require the skier to use their body differently. But the old techniques are also still available.

I guess most skiers have adjusted over the years, step-by-step. For me, it was a huge adjustment because everything had changed. It took me a while to get these new techniques down.

My first years in software

This whole experience reminded me of my first years in software. Today’s hardware and software provide a lot more options than when I first started out. However, getting the most out of these new options requires a different approach.

Cloud computing for example, provides many advantages over the older on premise solutions. They do require a completely different mindset towards IT and software – something that doesn’t always happen.

So ask yourself: am I applying the same mindset to today’s IT and software as I was 10 to 20 years ago?