Taming the Custom Software Project Beast
Taking on a custom development project is a huge task and one that oftentimes represents a career reputation activity for a CIO. No surprise, good CIOs tend to delay such projects until they know they are fully ready to go forward, reducing the chances of failure as much as possible. Unfortunately, many project demands from a programmatic perspective can’t wait for the perfect timing. Further, project failure is commonplace; close to two-thirds of major IT projects fail meeting their original goals once put into implementation and execution.
The main reasons for high risk in custom software development projects are many but the big common ones center around a lack of necessary skill sets being applied to the project, a lack of practical experience to knowing how to deal with ad hoc challenges, and ambiguous specifications from those who want the project to happen.
So why even consider custom software development at all? The option can be accused of being extremely frustrating. However, custom software still provides:
- Tailored software delivery that matches an organization’s business processes perfectly, which matters tremendously with confidential and highly unique ways of doing business.
- Custom software development can be scaled to match the organization. Off the shelf products are frequently one size fits all (which usually doesn’t fit well at all).
- Custom software delivers exactly what is needed. Off-the-shelf software typically has features and tools that aren’t needed and cause other issues.
So, there are big win areas possible, but CIOs need to pay attention carefully to what they are buying. And that also includes internal perspectives, which can cloud decision-making on software options and vendors. Some of the big areas CIOs need to focus on can really turn in to major dollar issues down the line. Here’s how:
Addressing Custom Software as a Product, Not a System
It’s easy to see custom software as just another product to implement in the office. However, that mistake often causes problems later when service and system benefits are then not implemented to their full potential. Custom software development is really a digitizing of a unique business process. In that respect, it’s not a consumable or replaceable. So what is chosen has to work every time going forward, not just until an expiration date occurs. The integration ideally means helping the work process increase productivity by improving every step for employees, not just providing a fancier color output document from a printer.
Ownership of the Code Doesn’t Happen
Again, this falls into the perspective of thinking that custom software development is a product. When a company buys a project, they are buying the setup and implementation; the source code still belongs to the vendor that created the system. Changes down the line will cost more fees, so these must be considered in cost planning for out years. The big cost drag can be in troubleshooting unforeseen issues needed post-project fixes, so incorporating this service provision up front and planning for future software enhancements in the project costs can save big dollars down the line.
Don’t Get Personal About the Project
Some CIOs take political positions on whether custom software development is a good idea or bad idea. From a strategic point and cost this analysis should be incorporated, but it’s a waste of time and energy to keep politicking when the decision has been made to go forward. It’s a far better approach to find the best vendor support among project bidders than to keep being a stonewall to the project.
Make Sure to Communicate Target Dates are Flexible Estimates
CIOs often get jammed because they let the folks they work with assume a project estimate is a hard delivery date. It’s easy to make that assumption during executive planning sessions because hard delivery dates are common commitments in other organization areas. However, the CIO is in a far better situation communicating soft estimates and ideal target dates with slippage possibilities so that surprises don’t occur when the date arrives. Nothing is worse than jamming a project with last-minute bad decisions because someone is trying to meet an arbitrary date.
Getting Caught Up in the Costing Trap
The fact is custom software development projects are incredibly hard if not impossible to accurately cost. Therefore, it’s a good rule of thumb to hold back 20 percent of a full project budget, letting folks assume it’s budgeted for less, to have the buffer in place financially to deal with unforeseen changes, ad hoc problems, and spec changes on the fly. It’s far better to obtain as big an estimate as possible and work every step along the way to stay under the radar for as long as possible. Prudence can win big at the project end when last minute resources are needed to get across the finish line.
People Make the Project
For all the wonderful automation tools and ideas out there, projects reach success because the people who are running them make the difference. A key risk in customized software projects boils down who is on the project team and their skillset. Too often the wrong people are chosen, and then the project becomes an ongoing challenge of managing a revolving door, replacing those who end up not being able to do the job with someone else in a pinch and repeating the exit process all over again with the next one.
Why are good teams such are hard challenge to create?
It's not that people are automatically bad at what they do; the problem with pulling together a good project team is that many companies don't put the necessary thought into the process from the start. Instead of looking at people's portfolio's and picking the right skillset for the job, they just hand the project to the internal folks who would have an investment in the area affected or the ones most likely to maintain it. Both are a mistake.
CIOs need to remember they hired many of their people to support and maintain existing systems, not necessarily to be project team members delivering a custom software solution. It's two very different dynamics involved.
Those who have an investment should be involved in the design scope to make sure a project is going to deliver what is needed, but that doesn't automatically credit them with the technological know-how to deal with vendor selection, procurement, scheduling, trouble-shooting and driving day to day success.
Those who have network maintenance skills will easily be able to provide input on what could overtax the existing system or where inputs need to be modified to interact, but that doesn't automatically give them the ability to create a new tool.
What's the Alternative?
Unfortunately, the two above groups often get chosen as team members by default because many CIOs confuse subject matter experts with the ideal skill for the project team. In fact, the very best skillset for a custom software development and implementation may very well be a brand-new set of personnel from outside, if affordable. They come into the project with eyes wide open, they have no existing programmatic biases, they are not pigeonholed by internal organizational politics, and they have something to prove for being hired on the team. These elements create a dynamic that can cut through the organizational barriers while still taking full advantage of the knowledge existing subject matter experts can provide.
Where a company can't bring in new blood directly, the CIO should be heavily considering a consulting approach instead. However, that consultant team should be different from the vendor providing the software tools (for instance, hire a Microsoft development firm, instead of Microsoft itself). Letting the two be the same provider sets up the CIO and his company for a collusion effect that will frequently cost more money and deliver less in substance. This is another area where managers often drop the ball, just wanting to take a one-stop-shop contract approach and not understanding what is exactly being bought. The more successful projects take a triad approach, retaining overall product ownership internally (requirements definition), using one vendor for the software development and delivery, and internal technical resources for ongoing maintenance and support after a thorough knowledge transfer. Differences are managed by the hiring company asserting overall directional control.
Don't Be Afraid to Take the Reins
Custom project software implementation can be challenging, but it's not an exercise of stumbling around in the dark. CIOs need to exercise their best know-how in planning and approach the matter creatively. The mistakes often made assume that existing processes and internal people can handle the project like any other task. Instead, CIOs need to go deep on long-range overall planning and then bring in the right people with the correct skillset to create the tool desired. Doing otherwise almost always contributes to project failure or delivery of far less than desired with a lot of ad hoc bad decisions made on the tail end to finish it.