Project Selection
Choosing what a company delivers to customers may be the core ingredient in company success. Large companies will run many projects simultaneously, but small companies often focus on one or two. When software development teams create solutions for internal use by the company, and there are not enough resources to create all the solutions every department requires, someone, usually a Project Management Office (PMO) must decide the priority of each project. When the software is used by the public and customers, marketing usually drives what features are delivered next. Some companies that allow a PMO or marketing or customer demand to drive project selection tend to select projects best in the short term for the customers, at the risk and expense of selecting projects that would be best in the long term. The development teams often know and understand the software solution the best and therefore may be better positioned to make the best selection for the next project. This is particularly true when the development team recognizes substantial changes to the architecture of the application would be valuable in the long term even though it provides no value to customers in the short tem. Unfortunately, in some organizations, the people deciding what projects come next and the development teams don’t work together to continually evolve the software infrastructure while also providing features to customers. In those environments, the software solutions reach a point where they can no longer be modified to support new features, and a solution rewrite must begin.
Other challenges in project selection include:
- choosing the projects that provide the best return on investment (ROI) instead of just those features with the greatest demand,
- recognizing that completing projects in a specific sequence provides a better result when the later projects can build upon the earlier projects, as opposed to needing to do substantial rework to the first projects completed to accommodate the demands of subsequent projects,
- understanding that some projects that will have little customer use may be more valuable to deliver early as a proof of concept of a new technology before that technology is used in more important solutions,
- understanding that a project has value not just for what it delivers to a customer but for the knowledge gained by development team members, particularly junior developers,
- and, in companies driven by MBOs and OKRs, aligning the most valuable projects with the company and department goals so that the most valuable projects can be worked on, instead of the projects that are easy to align with a quarterly or annual OKR or company goal.