The Top 3 Ways to Save Money on Your Next IT Project
Distance between management and involvement in IT deliverables can cost an organization time and money and a loss in staff, business, morale and respect.
Opinions expressed by Entrepreneur contributors are their own.
In my experience, there's typically a great deal of trepidation among executive leaders about getting involved in the specifics of IT projects. They may agree to broad ideas about implementing a new platform or building out an infrastructure to support a new line of business; but beyond that, it is rare to see upper management involved.
This distance between management and involvement in the underlying deliverables can cost an organization not only time and money, but also a loss in staff, business, morale and respect. If you are in a position of leadership at a company and engaged in (or planning to engage in) a large IT project, here are three primary moves you should take to ensure that your project ends with success.
1. Know what you want before you start development.
Do not move forward with the development of your project until everyone on the team can intelligently define what the end result of the project will be. There are many projects for which no one on the team, including management, can clearly define what the system being built is supposed to do or what it is supposed to look like.
In those cases, the project always ends in failure. After all, how can a team possibly complete a solution that has no clear definition? As a leader, you must be able to define the end goal and guide people on how to achieve that goal. You should be able to document the end result in a short writeup, and you should expect that everyone on the team be able to articulate and document the final result as well.
For example, say that you have an existing custom built solution that you want to migrate to a new CRM platform. Your goal should not be vague, by stating something like "We want to migrate our current solution to CRM." Rather, your goal should be, "We will move our current business processes and data to CRM platform X, and this is what that processis going to look like [add full definition here]."
By stating the need to move business processes and data, you will realize that your next step is to define the current business processes. If you don't have the ability to define the business processes, you will be relying only on coders to reverse-engineer the current system and rebuild it on a new platform -- which is not a path to success or cost savings.
Once these processes have been defined, you can then move on to technical documentation, and finally into the development of the system. In this way, you can save yourself time and money; so lay out your plan before you start.
Get involved in the details and follow a standard methodology.
For many executives, IT systems and code are black boxes that are untouchable. There is a reluctance and disinterest in getting involved (or fear of getting involved in something that is not a direct skill set). This is a critical mistake, and one that can cost organizations immense amounts of money.
Not only should you (or your company's executive leadership) be directly involved, but there should always be a business analyst involved who understands the business as well as the underlying technology. This person can act as a liaison between you and the programmers who are building the platform. Your role is to be actively engaged in the project, participating (at a minimum) in weekly status reviews and demanding demonstrations of the product on a regular basis.
Every solution should be developed in an iterative cycle, where there is always something to show. If your project has gone weeks without any demonstratable output, you are most likely on track for a train wreck. Stay personally involved and make sure you can talk to the specifics of the implementation if saving money and time is important to you.
Be strategic about resourcing.
A room full of internal staffers who are burned out, disinterested and perhaps even lazy is no match for one or two external contractors who are motivated by a fixed-fee project. Your company culture is a known reality to you, and engaging on a major IT project with staff that has underperformed in the past will not lead to success or cost savings.
If your internal staff are motivated and knowledgeable about the platform being implemented, fantastic! Otherwise, don't hesitate to look for outside help. If you are following a standard methodology to manage your project, you should have very specific tasks and hours that can be tracked, which will allow you to manage your resources accurately.
There are very few IT projects that require more than a few people to deliver successfully. If you are slated to start a 15-person project, take a step back and see if you can simplify the approach. Either deliver in smaller phases, reduce the project scope or have someone else come in and do a review.
The larger the team, the more likely the project is to fail. A small, agile, intelligent team can get far more done in a far more efficient way than virtually any large team. So, slash through the bureaucracy of your organization, use Agile methodology to manage the project and work with a team of people that can get things done!
No one can fully define a system up-front, but being prepared to define the minimum viable product (MVP) and iterate on that throughout the project until a fully functional product is available is what allows a project to succeed. Before you begin development, make sure you can define the end result. Make sure you have someone who can translate business needs into features and functions, and who can work with others to translate those into designs and code.
Make sure you are smart about the resourcing and management of the team members. And, finally, stay involved throughout! If you are involved, you can react immediately to issues that arise. If you are not involved, your project will take on a life of its own and --even if it succeeds -- end up costing your company considerably more time and money than it should have.