When working on any project, we often get so focused on the outcome (the shiny objects) that we forget the basics. The most important of these is stakeholder engagement in answering the fundamental question, “What problem are we trying to solve”. Once agreement on the problem definition is reached, then the project roadmap must be developed followed by the project plan. Both of which also must be completed with input from the stakeholders and must include an overview of why we are committing resources to the initiative. The roadmap informs stakeholders of the technical approach, gap analysis, and workflow sequences. The project plan provides a granular view of detailed tasks along with assigned responsibilities and timelines for delivery to track all features of a project.

My personal tenets of technology project management:

• What are we trying to solve – Validate whether a legitimate business need actually exists, not product hype. This is usually sorted out by insisting that the business provide at least an estimated return on investment (ROI).
• Never build a software solution when you can buy – Building custom software comes with increased costs and future support issues, while a commercial, off-the-shelf (COTS) product comes with regular updates and future new features. A reputable company’s COTS product has been through rigorous testing and review by exiting customers who have identified issues that have been resolved. Additionally, future release support includes the ability to deliver new functionality.
• Map current workflow processes – One of the most controversial issues I have dealt with over my career is the insistence on keeping the current workflow processes, which have not been changed for years, versus the adoption of processes within the new solution. The interesting, and most frustrating, part about this is that many customers have never taken the time to identify their organization’s current workflow processes. They just know that they don’t want to follow the new process built into the tool, regardless of whether it is a more streamlined process and, in some cases, even automation of current manual processes.
• Validate customer availability – The customer commitment (hours of availability) must be documented and integrated into the project management process. Customer management is essential in the successful management of projects.
• Don’t customize, configure – COTS systems can normally be customized, and customers always want customization. Customization results in increased time to production, increased risk, and most importantly enhanced complexity and added cost when upgrading to more current versions. Heavily customized COTS systems often cannot be easily upgraded and, in many cases, become the future legacy system of our inventory. Often the argument for customizing existing system code is the additional functionality it provides, which also becomes its weakness in the form of challenged execution. Software providers have already spent the time and resources to research and deploy industry best practices. Keep it simple – according to McKinsey 56% of large IT projects fall short of their original vision and project success rates inversely correlate with the complexity of its features.
• Don’t compound your problem – Is customization of the COTS software necessary? This is the first warning sign of future costs to support and upgrade. Required customization assumes that the customer knows exactly what they need. Unfortunately, that is seldom the case.

Don’t start any project prior to addressing these basic factors:

I was sent the image below that made me think about my personal tenets of technology and project management that I have learned over the years. I will admit, most by learning from my own mistakes. Number one on my list is to determine all current system dependencies within the organization. In other words, don’t build anything on top of unsupported products. Too many times in my past I have been moving forward and making great progress on a project just to find out that there was a dependency downstream on a product that was out of support or end-of-life. Totally derailing the project for weeks or months.

When I began my career, we had very little options other than to build software to fit our specific needs. The commercial product offerings were simply not available off-the-shelf. I can’t imagine an organization developing unique systems today like we did then. Today software providers capitalize on developing proprietary software to take advantage of economies of scale by building once and selling to numerous customers. This network of customers in turn force new functionality and invite the formation of independent support vendors with skilled staff further enhancing your investment and mitigating your risk. Software in broad use with a company history of historical success increases guarantees of future support, interconnectivity and interoperability.