To answer this question we need to think about why we hire an employee. Several scenarios exist and some are very positive but others...not so much. For example, if you hire a salesperson to manage a new sector it's probably a good sign: more sellers, more sales, more revenues. However, if you hire someone to delegate or distribute administrative tasks, its obviously less profitable: more employees, more spending, same revenues, less profits.
I'm not trying to say that no employee should be assigned to administrative duties. However, I am clearly saying we must keep this number to a minimum. How? Often by setting up an effective management software.
To help you understand my point, imagine a small company that has two employees. These two employees are the heart and soul of their business and must work more than 60 hours per week. Having a little more income, they decide to hire a third person to delegate administrative tasks. Doing so, they reduce their weekly effort to 45 hours. Problem solved! More or less. An employee hired will cost at least $ 25,000 per year. This person does not sell and is not attributed to business operations. We're therefore confronted to an expense: what I call an "expense-employee".
If, instead, these entrepreneurs had invested in software that managed their billing, accounting and operations, they might find themselves in better posture after a short amount of time. Such software, if well established, could allow our entrepreneurs to reduce their workload substantially since they will not have to enter data redundantly through their various systems. They'll avoid hiring someone and, once the software is paid, its more profits straight in their pockets.
It is true that custom management software for a small business can cost in the tens of thousands of dollars. However, compared to the salary of an employee, it's an expense that is only done once. Small businesses will therefore find a return on investment usually within a year.
Another important advantage of custom software is that it provides guidance to employees. Without software, processes are known only by employees. They therefore all become key employees. They are expensive and essential to the business. With good software, processes and data are contained in the software, facilitating the work of employees, reducing their training time and making employee rotation less of a hassle.
By making such remarks, I'm often told that if everyone thought like me, we wouldn't have jobs as we would all be replaced by "machines". Nothing is farther from the truth. My goal is not to reduce the number of employees but to increase the proportion of employees with added value vs. "expense-employees". What must be understood is that in the business world when spending is reduced, profits are increased. This usually translates in a greater re-investment in the company to increase revenues and grow the business and thus increasing the number of employees.
This article is meant as a wake up call for entrepreneurs that are on the verge of hiring but that haven't yet put proper processes and software in place. There are obviously a lot of circumstances and all businesses are different. Nevertheless, when the time comes to hire, take the time to ask yourself: why am I hiring? Could it be avoided? Would a proper software help me reduce my current tasks and better support my current and future employees? What is the best investment?
Power your Business with Smart Software Decisions
Small businesses are often overwhelmed with software decisions. We all want to keep the expenses to a minimum yet so much time is spent keeping organized and managing administrative tasks. How do you choose which solution is right for you?
Sunday, February 2, 2014
Tuesday, August 6, 2013
Understanding the different IT trainings
IT sciences have been around for quite a while but it has known an
incredible growth in the pas 20 years. In fact the growth has been so
quick that the trainings related to this "new" profession have been a
little foggy for a while. The demand has been so strong that anyone
could (and still can) improvise himself as an IT specialist without any
real training.
Is this a problem? Not necessarily. However, it's worth taking a deeper look in the different IT trainings to understand their differences and what each are meant to accomplish.
1- Computer Engineering
A computer engineer has at least a bachelor's degree in engineering. The engineer will learn much more than just how to handle IT tasks. In fact the engineer learns how to come to solve problems as best he can within the means available to him. He will be taught many disciplines that he will never even cross in his professional career in order to make him appreciate the diversity of problems that he can come across.
The engineer also has a civil and ethical professional responsibility as specified by his Order.
In practice the engineer will only learn the fundamentals of programming or other IT tasks. His training is more focused on how to evaluate, approach and solve a general IT problem according to the given situation: economics, schedule, actors, etc. The methodology takes precedence over the knowledge of the tools.
2- Computer Science Bachelor Degree
Such a degree is more focused on the practical application of computer sciences. For example, for software, the Computer Science Bachelor Degree will teach several programming languages as well as the different IT roles and their relationships (quality assurance, development, support, architecture, etc.).
The university graduate therefore has all the tools to start a career in the IT sector.
3- IT Technical Degree
The technical degree allows the student to learn a particular sector of the IT sector in less time. Generally the graduate will have all the necessary knowledge to tackle a specific sector (i.e. multimedia, quality assurance, 3D programming, etc.). He will, however, possess less knowledge of other surrounding IT areas and their relationship with his own.
4- IT Certificate
The holder of the certificate is taught a very specific part of the IT business. Examples of certifications are: Project Management Professional, Virtualization Professionnal, Cloud Professional, Systems Security Professional, etc.
Depending on the type of job, this can be more than enough if the job requires only this ability or if this ability complements other knowledge.
5- Self Taught Training
Also known as autodidact. The self taught has no certified training but has learned through tutorials, books, seminars, etc.
Each training has a purpose. My role is not to judge which training is better than another. It depends on the candidate and the employer's desires and needs. Someone who wishes to specialize in a very specific portion of the IT sector will be more than satisfied with a Technical Degree or a certificate. Whereas someone who wishes to learn a wider scope of the IT world might go for an engineering or computer science degree. From the employer standpoint, the training is often more pertinent in the first few years of a candidate's career (except for specialized certifications requiring a certain level of expertise). Depending on the position he wants to fill, odds are that someone who has training is better prepared versus someone who has none.
This is all very theoretical. In practice, I have seen great incompetence in IT engineers as I have seen some of the most brilliant and structured IT specialists to be self taught. I've learned to evaluate IT specialists based on practical skills rather than their theoretical trainings. I will not deny that in general I find engineers and bachelors to have a better structure and organizational approach in their work. Technicians, that are self taught or that have uniquely a technical degree, will often find a way to solve the given problem but without necessarily thinking through the medium or long term impacts. I have often refused contracts from clients who wanted my company to take over a project simply because these projects were developed by amateurs making the projects "irrecoverable". But these are generalizations...
In my opinion, training gives us a good indicator on the dedication, the structure and the ability to adapt of a given IT Technician. That said, we all end up learning a lot more with our job experiences through out our careers than though our trainings. We must therefore find ways to judge the individual and his experiences rather than his trainings...
Is this a problem? Not necessarily. However, it's worth taking a deeper look in the different IT trainings to understand their differences and what each are meant to accomplish.
1- Computer Engineering
A computer engineer has at least a bachelor's degree in engineering. The engineer will learn much more than just how to handle IT tasks. In fact the engineer learns how to come to solve problems as best he can within the means available to him. He will be taught many disciplines that he will never even cross in his professional career in order to make him appreciate the diversity of problems that he can come across.
The engineer also has a civil and ethical professional responsibility as specified by his Order.
In practice the engineer will only learn the fundamentals of programming or other IT tasks. His training is more focused on how to evaluate, approach and solve a general IT problem according to the given situation: economics, schedule, actors, etc. The methodology takes precedence over the knowledge of the tools.
2- Computer Science Bachelor Degree
Such a degree is more focused on the practical application of computer sciences. For example, for software, the Computer Science Bachelor Degree will teach several programming languages as well as the different IT roles and their relationships (quality assurance, development, support, architecture, etc.).
The university graduate therefore has all the tools to start a career in the IT sector.
3- IT Technical Degree
The technical degree allows the student to learn a particular sector of the IT sector in less time. Generally the graduate will have all the necessary knowledge to tackle a specific sector (i.e. multimedia, quality assurance, 3D programming, etc.). He will, however, possess less knowledge of other surrounding IT areas and their relationship with his own.
4- IT Certificate
The holder of the certificate is taught a very specific part of the IT business. Examples of certifications are: Project Management Professional, Virtualization Professionnal, Cloud Professional, Systems Security Professional, etc.
Depending on the type of job, this can be more than enough if the job requires only this ability or if this ability complements other knowledge.
5- Self Taught Training
Also known as autodidact. The self taught has no certified training but has learned through tutorials, books, seminars, etc.
Each training has a purpose. My role is not to judge which training is better than another. It depends on the candidate and the employer's desires and needs. Someone who wishes to specialize in a very specific portion of the IT sector will be more than satisfied with a Technical Degree or a certificate. Whereas someone who wishes to learn a wider scope of the IT world might go for an engineering or computer science degree. From the employer standpoint, the training is often more pertinent in the first few years of a candidate's career (except for specialized certifications requiring a certain level of expertise). Depending on the position he wants to fill, odds are that someone who has training is better prepared versus someone who has none.
This is all very theoretical. In practice, I have seen great incompetence in IT engineers as I have seen some of the most brilliant and structured IT specialists to be self taught. I've learned to evaluate IT specialists based on practical skills rather than their theoretical trainings. I will not deny that in general I find engineers and bachelors to have a better structure and organizational approach in their work. Technicians, that are self taught or that have uniquely a technical degree, will often find a way to solve the given problem but without necessarily thinking through the medium or long term impacts. I have often refused contracts from clients who wanted my company to take over a project simply because these projects were developed by amateurs making the projects "irrecoverable". But these are generalizations...
In my opinion, training gives us a good indicator on the dedication, the structure and the ability to adapt of a given IT Technician. That said, we all end up learning a lot more with our job experiences through out our careers than though our trainings. We must therefore find ways to judge the individual and his experiences rather than his trainings...
Wednesday, July 3, 2013
Who's right? Client or programmer?
In the software programming world, particularly custom software, many debates rise between clients and programmers. These constructive discussions tend to focus on how a specification should be reflected in the upcoming software. The question is: is the client always right?
The client pays the bills so in the end so whatever happens he'll have the last word. This being said, its important to listen to both point of views because they both bring important and distinct information on how to tackle the problem.
Here are a few examples of typical views in these debates:
1- The programmer wants to build the simplest possible solution
This is quite frequent. If you ask a developer how to build a particular specification, chances are, he'll suggest the easiest "technical" solution. This might be the easiest solution and also the cheapest solution (in direct costs) but it isn't necessarily the most effective.
This kind of thinking has put forth some great technical software designs on an engineering standpoint but horrible in terms of user experience and efficiency.
Good examples for this are the operating systems in smartphones. Before the IPhone, smartphones had evolved capabilities such as email and web browsing but they were so un-user-friendly, that they were very scarcely exploited. Why? Because the designers thought of functionnality first and user efficiency second. Apple changed all that by providing tools that were, yes a little more powerful, but immensely more user-friendly.
As a matter of fact, Apple revolutionized the whole way of thinking in terms of customer based approach for technological devices. A device with the same kind of hardware will be WAY more profitable if it offers a more ergonomic interface than its competitors.
2- The client is not aware of the importance of data integrity
Obviously the programmer isn't always wrong. Let's take an example to illustrate this point: customer management. Every other software manages customers (add, remove, edit customers, etc). Whatever the software, the customer is usually binded to other entities such as bills or orders. One of the specification a client might ask is to be able to delete a customer. Its obviously technically possible but what will happen to all the binded entities? Should the bills and orders not refer to that customer anymore? Obviously not. If we did, we would be left with bills and orders that point to no customer. This is a clear example of going against data integrity. I won't go into details, but as a programmer that is the most important thing to avoid.
For a programmer, this kind of "data integrity problem" is obvious, but it won't be for a client. The solution to this particular problem is to find a way to remove the customer without affecting the data integrity. The typical solution is to allow the customer to be archived. The data is note deleted per se, it still exists in the database, but it won't be visible through certain user interfaces. This is a simple example to illustrate my point but this can get quite tricky with large software solutions.
3- The client is not aware of the cascading consequences
"All I want is a list of my employees". This may seem like a pretty straightforward specification but many questions will derive from it: Can we sort this list? Can we filter it? Which information should we see for each employee? How many should I see per page? All? And if there are 50 000? Do I want to export this list in another format (excel, pdf)? Etc.
As you can see, the basic specification can have many cascading specifications related. The discussions between the client and the programmer will help the client evaluate what the range of possibilities is and allow him to make an informed decision.
It's a bit like going to a car dealership and asking: "I want a car." A car can cost as little as $10,000 but can also be worth more than $100,000.
4- The programmer does not predict the user interactions
When we develop a software, we use it in a certain way through our tests. Since we built it, we use it as it "should" be used. But the end-user does not know how it was built and therefore does not know how to use it. He'll use it the way he thinks it should be used. And that's normal!
Its the responsibility of the programmer to take the time to think of the different ways the software can be used and to guide the user through an ergonomic software to use it the right way. But even by trying to predict how users will use it, we're always surprised at how they end up using it. Its therefore even more important for programmers to sit down with end users after releases or pre-releases and explore how the software is used. This will help improve the software according to the different users and their feedback.
What we need to remember through all of this is that good communication between programmer and client is essential. These kind of debates are not bad. On the contrary, they must take place. In the long run, the results of these discussions will help build a stronger, more efficient software.
UX (User experience) is a specialty that is born through these kind of debates. The UX specialist works between the client and programmer to help find the most efficient design for the client while taking in account the programming constraints. This will help the client get an ergonomic software that meets the data integrity requirements.
The client pays the bills so in the end so whatever happens he'll have the last word. This being said, its important to listen to both point of views because they both bring important and distinct information on how to tackle the problem.
Here are a few examples of typical views in these debates:
1- The programmer wants to build the simplest possible solution
This is quite frequent. If you ask a developer how to build a particular specification, chances are, he'll suggest the easiest "technical" solution. This might be the easiest solution and also the cheapest solution (in direct costs) but it isn't necessarily the most effective.
This kind of thinking has put forth some great technical software designs on an engineering standpoint but horrible in terms of user experience and efficiency.
Good examples for this are the operating systems in smartphones. Before the IPhone, smartphones had evolved capabilities such as email and web browsing but they were so un-user-friendly, that they were very scarcely exploited. Why? Because the designers thought of functionnality first and user efficiency second. Apple changed all that by providing tools that were, yes a little more powerful, but immensely more user-friendly.
As a matter of fact, Apple revolutionized the whole way of thinking in terms of customer based approach for technological devices. A device with the same kind of hardware will be WAY more profitable if it offers a more ergonomic interface than its competitors.
2- The client is not aware of the importance of data integrity
Obviously the programmer isn't always wrong. Let's take an example to illustrate this point: customer management. Every other software manages customers (add, remove, edit customers, etc). Whatever the software, the customer is usually binded to other entities such as bills or orders. One of the specification a client might ask is to be able to delete a customer. Its obviously technically possible but what will happen to all the binded entities? Should the bills and orders not refer to that customer anymore? Obviously not. If we did, we would be left with bills and orders that point to no customer. This is a clear example of going against data integrity. I won't go into details, but as a programmer that is the most important thing to avoid.
For a programmer, this kind of "data integrity problem" is obvious, but it won't be for a client. The solution to this particular problem is to find a way to remove the customer without affecting the data integrity. The typical solution is to allow the customer to be archived. The data is note deleted per se, it still exists in the database, but it won't be visible through certain user interfaces. This is a simple example to illustrate my point but this can get quite tricky with large software solutions.
3- The client is not aware of the cascading consequences
"All I want is a list of my employees". This may seem like a pretty straightforward specification but many questions will derive from it: Can we sort this list? Can we filter it? Which information should we see for each employee? How many should I see per page? All? And if there are 50 000? Do I want to export this list in another format (excel, pdf)? Etc.
As you can see, the basic specification can have many cascading specifications related. The discussions between the client and the programmer will help the client evaluate what the range of possibilities is and allow him to make an informed decision.
It's a bit like going to a car dealership and asking: "I want a car." A car can cost as little as $10,000 but can also be worth more than $100,000.
4- The programmer does not predict the user interactions
When we develop a software, we use it in a certain way through our tests. Since we built it, we use it as it "should" be used. But the end-user does not know how it was built and therefore does not know how to use it. He'll use it the way he thinks it should be used. And that's normal!
Its the responsibility of the programmer to take the time to think of the different ways the software can be used and to guide the user through an ergonomic software to use it the right way. But even by trying to predict how users will use it, we're always surprised at how they end up using it. Its therefore even more important for programmers to sit down with end users after releases or pre-releases and explore how the software is used. This will help improve the software according to the different users and their feedback.
What we need to remember through all of this is that good communication between programmer and client is essential. These kind of debates are not bad. On the contrary, they must take place. In the long run, the results of these discussions will help build a stronger, more efficient software.
UX (User experience) is a specialty that is born through these kind of debates. The UX specialist works between the client and programmer to help find the most efficient design for the client while taking in account the programming constraints. This will help the client get an ergonomic software that meets the data integrity requirements.
Tuesday, May 14, 2013
5 clues that it's time to rewrite your software
A software rewrite is never an easy task. A rewrite consists of taking an existing software and rewriting it to better accommodate the client. Although, it can be quite tedious, it is often necessary. In this post, I'll explore certain clues that can help indicate when its time to consider rewriting your enterprise software.
The common reason: "its time we changed, we built it 5 years ago" isn't valid by itself. If you've maintained and updated your software through out the years, chances are its still a valid and acceptable solution today. Age by itself is not a reason but can often be an indirect reason why you should rewrite your software. There are many things to take into consideration. One of which is that rewriting a software years later will probably cost way less than it initial cost.
Software Development Progression: A software built 10 years ago could cost 5 times more than it would cost to build today (dummy data) |
Here's my top 5 clues that its time to proceed to a software rewrite
1- You don't dare modify your current software
A well designed software should not only be durable but must also be easily modifiable. An enterprise software solution should be updated regularly to meet the enterprise's evolution.
Therefore, if you haven't updated your software for any reason (fragility, cost, etc.), it's time to investigate if it isn't time to change that software altogether because chances are its not meeting your exact needs today.
2- The modification cost is very high
Technology evolution tends to facilitate the software development. For instance, a web site that could take months to put up a few years ago can take just a few days using modern technologies such as WordPress. So even though your software is up to date and still works fine, its possible that every change, as small as it may be, can take a lot of time and cost a lot of money. Its not necessarily because the software wasn't built correctly. It simply means that there might be more recent technologies that can help you diminish those costs.
If you've noticed that maintenance and evolution costs for your software are very expensive, it might be time to investigate a rewrite.
3- You can't find a company or consultant to take over your software development
Technologies are evolving quickly and many programming languages are losing traction. Cobol, for instance, isn't as popular as it used to be. Yes, some systems still run on them but since there aren't that many such systems, Cobol programmers cost a lot more than, say, mainstream Java programmers.
Again, if you're having trouble finding suitable people to take over or maintain your software solution or if the price is too high, you need to start thinking about what it would cost you to rewrite your software and diminish your costs in the long run.
4- You patch your software with Excel spreadsheets
Classic! Creating databases directly in Excel is the classical way for small and even large businesses to fill the gaps of their existing software solutions. Excel is not a database! Yes you can keep some information in there but the info is not indexed, normalized or available in a proper collaboration tool.
Ideally, you would fill those gaps in your existing software solution allowing you to centralize your data and manipulate it with more ease. By adding Excel sheets (or any other patch), you're filling in a gap but delaying the problem. You're adding a complexity in your overall infrastructure that can end up costing a lot if you depend on it.
If you use Excel spreadsheets as a database, its a definite clue that your software should be updated... and if you're not updating it...then go back to point 1 :)
5- Your operation productivity is in shambles
In my honest opinion, the goal of your software solution is to encapsulate and simplify your operation process. If you find that your operations could be optimized but are not because you're following the process put forth by your software, you're definitely facing a clue that you should change your software suite. Software should adapt to you, not the other way around. As a business manager you need to find ways to optimize every area of your business. You also need to put forth tools that will help you manage these optimizations. If your tools aren't tailored to your operations, you're probably losing some money in the process.
Don't forget that I'm putting forth clues and not diagnostics in this article. Your business might well meet all the above criteria and you still might not need to rewrite your software. But if it does meet one of these criteria you should at least look into it to see if you shouldn't put forth a plan to eventually rewrite. Remember that a good software solution can make a huge difference.
Tuesday, February 12, 2013
5 tips to better manage your multiple software solutions
In the business world, it is rare to find an enterprise that has a single software solution that meets all its needs. Generally, the businesses, especially the small businesses, will have a multitude of software solutions that, put together, meet the majority of the business' needs. But at the same time, some of these software will have functionalities that will intersect between one another. The superfluous caused by this redundancy is far from ideal but, if well managed, can be more than acceptable.
Here are 5 tips to help you better manage this situation:
Friday, September 28, 2012
Apple's rare mistake: Maps
Its rather difficult to find obvious flaws in the marketing and Apple product placement in the last decade. But in their new operating system, IOS6, Apple made a huge one. One that could have been avoided: including and replacing an existing software with one that wasn't ready yet: Apple Maps.
The Public Transportation directions are not in Apple Maps. Instead we are redirected to a screen suggesting other apps. |
Sunday, November 20, 2011
Choosing IT solutions based on your business' size
IT is a complex domain.
For a given problem, there'll always be a great number of solutions.
Each solution has its pros, its cons and an associated budget. The
choices to be made for a small business are far from obvious but
here's some advice on how to take in account your business reality to
your IT needs.
Subscribe to:
Posts (Atom)