Backing Into The Project Plan

When a new concept for a software solution is conceived of at the corporate level, it doesn’t always come prepackaged with specifications or even sufficient grounds in reality to know if the concept can be done. This is often the disparity that occurs when business managers “think up” software solutions. Many business leaders, who may be quite brilliant in the business side of your enterprise, conceive of a software solution to a business problem or a technical innovation to make the company more profitable. Sadly sometimes the original idea may have more in common with science fiction than science.

But nonetheless, the software problem is often delivered to IT management and project developers with the charge to “make it happen” or at least come back with a feasibility study as to whether the proposed solution would reap the rewards.

It is not up to IT to limit the imagination of management so it is a routine procedure for project planners within IT to research how to go about putting together the solution. If you can find similar software products or systems in the marketplace, you are encouraged because that means you may be able to come back to management with a proposal to achieve all or part of their dream for a software solution to address the very real and very present needs of the business.

The problem arises when you need to be able to put some detail around the idea of a software solution but you may not have sufficient design work done to make that a reality. This is where some creative methods to “back into” the software design and the project plan can give you a lot of design detail that is the result of someone else’s hard work and in depth development R&D which saves you a lot of effort and still allows you to deliver a good solution back to management.

The software developers who have already put together a similar solution as your concept suggests can be a tremendous source of detail to help you with your feasibility study phase of the project. The routine method for putting a project out for RFP to outsource software development is to have a significant amount of the requirements definition and the project plan developed so you can specify to the contracted developer how the process will unfold.

But the model we are suggesting for actually using proposals that come back as a result of the RFP to provide you with detail for your feasibility study approach the problem differently. Software developers who hope you will out source the final project to them are often very forthcoming with details, costs and design flowcharts to submit as a proposed solution to your business and IT problem. You just have to tap that desire to capture your business and you can harvest a wealth of design information and harvest it for free at that.

After you identify the short list of potential developers who may have a solution already designed, you can put together an RFP that is built entirely around a description of the business problem. The challenge is given to the developer to submit not only a proposal for the cost of their proposed solution but a detailed description of how their proposed solution solves the problem you laid out in the RFP.

This approach to gathering specifications from developers can use the expertise of those who wish to capture your outsourcing business to give you a network design, hardware specifications, software recommendations, costs and development time frames that can jump start your project planning considerably. It is not unethical to exploit the talents of established contractors because you very well may use them after all. You simply are benefiting from a nuance of the outsourcing process that can yield you a wealth of free information to make you not only look smart to your superiors but more intelligent about the potential solution as well.