If you are like most construction executives, you don't view yourself as a software technology expert.
In fact, you probably approach new information technology (IT) projects with trepidation and hand it off to the back-office staff or third-party consultants. This is an understandable and healthy fear given that the majority of software projects fail.
This is also one of the reasons why the construction industry lags behind other industries in software technology adoption. While large manufacturers, retailers and financial services firms charge into the 21st Century with optimized supply chains and web-based customer management applications, too many small or mid-size contractors are still estimating with pencil and paper or job costing with a pocket full of receipts.
The good news is that you already have the experience you need to change your company's success with IT. The same skills that make for effective construction estimating and project management can be applied to software selection. Just like constructing a new building, selecting software requires a detailed set of plans, an accurate budget and meticulous project management.
Get over your fear of technology, and you can be on your way to the first of many successful IT projects. It won't be long before these projects result in more accurate estimates, more efficient projects and a healthier bottom line.
Why So Many Software Projects Fail
There are many reasons why IT projects fail, but we've isolated what we believe are the top five reasons:
- Limited budgeting and planning
- The wrong team for the job
- Poor requirements planning
- Lack of a rigorous selection process
- Weak change management or training
Ten Steps to Successful Software Selection
Now that we have identified the leading reasons for IT project failure, we will outline in ten clear steps how construction companies can manage an efficient selection process that ensures success.
Assemble the Right Team. Start with identifying an executive-level project sponsor who will ensure the project gets the right funding and attention throughout the organization. Next, you'll need a project manager who will oversee all details of the project from start to finish. If you have an IT staff, they obviously have an important role to play in the process, but don't let your software decision become exclusively technology-focused. Finally, you'll need to identify end-users that will enthusiastically contribute their requirements and ideas for improving processes.
Establish Clear Goals for the Project. Once the team is selected and assembled, a good first step is to outline the goals of the project. These goals will justify the project expense and guide the team as difficult decisions arise. All choices during the project should be weighed according to how well they help achieve goals, such as: develop more accurate estimates, improve coordination between the field and the office, or speed up change order approvals or submittals.
Build a Detailed Project Schedule. The next step is to create a project schedule that outlines all the major activities and their sub-tasks. Just like a construction project, you should consider each activity's various dependencies and resource requirements. Be sure to assign an owner to each activity and even to each task. The project schedule itself can be as simple as an Excel spreadsheet to track the various tasks or as sophisticated as using your existing project management software to manage the project with Gantt charts and a Critical Path Method network diagram.
Create a Budget for the Project. An otherwise successful software project could be considered a failure if it comes in over budget. That's why it is critical to have an accurate budget to work against. The biggest budgeting problems occur when the project team fails to account for costs outside of the software itself, such as new computer hardware required to run the software, platform software requirements such as a new database or consultants to help install and customize the software.
Define Your Requirements. The next step is perhaps the most important in the entire process: Defining the functional and technical requirements you have for the new system. As software selection practices have evolved, requirement planning has shifted from simply a list of features-often influenced by software vendor marketing-to a more deliberate, thoughtful analysis of "current" versus "optimal" business processes. This requires that the project team maps out existing business processes and then considers how each could be improved. Exhibit 1 illustrates a "before and after" flow chart for an optimized "punch list" process.
Draft a Request for Proposal (RFP) and Evaluation Framework. The RFP will take the form of a Microsoft Word® document of questions that can be sent to software vendors for their response. It should cover all of the features and functions identified as critical during the process mapping stage. It should also cover technical requirements, such as which databases and operating systems are supported, or if the software is offered as "Software as a Service" such that it is hosted by the vendor and accessed over the Internet through a web browser. An evaluation framework is a spreadsheet in which you track each product's capabilities relative to your list of requirements. Typically this would consist of a Microsoft Excel® spreadsheet with all of your requirements listed in rows down the left side and each of your short list vendors represented by a different column, such as the illustration in Exhibit 2.
Develop a Short List of Products. Next you should create a "short list" of software products-three to five products that meet your high-level requirements. If your short list grows beyond five vendors, you will not likely be able to evaluate each in sufficient detail. If the shortlist is less than three, you are probably overlooking a few good products. To build a shortlist, start with a longer list of products assembled from numerous sources, such as industry trade magazines, especially annual tech issues; trade shows and conventions; and recommendations from peers or advisors (e.g., CPA's). Filter the list down to three to five products based on questions such as:
- Does the company serve your specific trade?
- Do they serve your size of business?
- Do they present a professional image (e.g., quality website)?
- Do they meet your technology requirements (e.g., database)?
Evaluate Short List Products. The next step in the process is to evaluate your shortlist of products to choose a single "winner" and a contingency "runner-up" in case reference checks or negotiations don't go well with the first vendor. Start by sending each vendor a copy of your RFP and ask them to complete it. Concurrently, begin collecting information from each vendor such as brochures, papers, trial versions of their software and demonstrations. As you review this information, use your evaluation framework to track how well each vendor's products match your requirements. After completing all of the demonstrations and reviewing the RFP responses and product literature, it is time to review the evaluation framework in detail and rank each product. Using the feature-by-feature scores you entered for each product and the weightings you assigned to each requirement, rule out any product that falls short of your most critical requirements. Then, prioritize the others according to their performance across all of your important requirements. Finally, select one vendor that you feel is best, as well as a runner-up.
Check Customer References. It is critical at this point that you do your due diligence by checking the winning vendor's customer references. Moreover, you need to "play detective" and dig into these references. Keep in mind that the references to which a vendor refers you are most likely their happiest customers. To offset such "cherry picking," require at least three customer references, and prepare a detailed list of questions that require specific answers rather than broad, positive generalities. Even better, try to locate your own customer references by networking with industry peers, attending trade shows or user groups and talking to your industry association.
Negotiate the Deal. The final step in your selection process is negotiating the right deal. Don't stop being diligent just because the finish line is insight. This step of the process will determine the price you pay for the software, the level of service you receive and the recourse you have if things go wrong. Key areas to consider in the negotiation include:
- What type of license does the vendor offer?
- How is the software priced?
- What are the maintenance and customer support policies?
- What are your rights to new versions of the software and periodic upgrades?
Keep in mind that for medium- to large- size deals, there is typically room to negotiate with the vendor on all of these points. The larger the check you are asked to write, the more room for negotiation.
Software selection is not easy and should never be considered a second tier project. The right software, implemented properly, can have a major positive effect on your business. Follow these guidelines and you are on your way to IT project success.
Construction Business Owner, November 2006
