In few steps, develop a good solution that fulfills THE needs AND requirements.
"Did you ever made a simple order that went totally wrong?"
The more your solution fits the business needs the better your chances are that your client will be willing to pay for it. Of course, economically, your solution needs to be sold at the right price point that the client is willing to pay for. If you know that the price point is too low right up front, do not invest one penny trying to develop it!Still today, I see a lot of companies trying to push solutions to clients that THEY THINK will fulfill their needs. Millions of dollars are unfortunately lost in development projects that die before they even have a chance to see the day.
Why? Too many companies do not invest enough in the most important phase of a development project (which is the identification the business needs and development of a business case). They jump right away on the "HOW" and do not spend enough time trying to understand the "WHY" and the "WHAT".
One of my client signed a contract last year in regards to a development project. An assessment was performed by some systems architects prior to the sell and a USE CASE (high level requ's). You have no idea how much effort was put into it, there was so many discussions with product management and with the solution experts. At the end of the day a great document was created on how they thought the solution should work. But NO ONE involved clients to validate the assumptions and the use case! Everything made sense for everyone at a high level. Sales signed a contract with a first client and couple of weeks after the kick-off guess what? Yes, the project has not started yet and major show stoppers were identified by the client already! So we had to put a hold right away on the project to step back and reset the contracts. Please if you are a software company, always, always, always sell a solution architecture phase prior to signing the development contract. How can you sell a license for a new development that you have not scoped properly yet?
Some tips;
- Involve your clients to understand the business requirements. You can conduct focus group sessions. Make sure to understand how the requirements will impact the business processes of clients. Try to extrapolate the benefits of the features and potential impacts on the KPI's. Try to be as pragmatic as possible, go as far as documenting the process flows to really think of everything. Document the preliminary assumptions and components that are definitively out of scope versus in scope. GO OR NO GO?
- Develop a business case. Calculate ROI, how is it going to cost to develop the features? What is the CTO (Cost of Total Ownership)? How long will it take to make the development and will we be on time to market? What is the customer price point? Is the margin acceptable? What are the risks? What are the sale forecasts expected and customer target? How much will it cost to market? GO OR NO GO?
- Developing a solution architecture is like building a puzzle. You first make sure that you have all the pieces you need and then you put your pieces together to build a clear vision from all angles. How will all the pieces integrate together? Which piece touches which piece of the puzzle? Usually a solution architecture diagram is used to illustrate the 'puzzle' as well as each components. Solution architecture document template can be found in internet easily. You want to ensure that you build a technical architecture at the same time that you build your solution architecture. Both dimensions need to work together. For example, you may want to integrate a master file but also need to clearly identify how the master file will be integrated technically (bidirectional interface?, only sending unidirectional info?)...
- The solution architecture needs to be enough detailed and documented so that everyone understands what needs to be done to support the business need identified and future state targeted. The solution architecture shall be approved by the client and should be enough detailed to estimate development costs. Client will need to know the development costs before signing the solution architecture. If there are some budget constraints, the solution architecture will be developed with the budget in mind. The you estimate the costs of development with a better level of precision. You also document the assumptions. You will have another GO NO GO to make, is it worth it? Is this development aligned to your product strategy? Does it make sense for the client?;
- Do not underestimate the time it will take to validate and approve the solution architecture. The development of the solution architecture can take anytime from 6 weeks to 6 months depending on the complexity of the solution to create and depending on the methodology used to do so.
Ask me more questions if you need!
No comments:
Post a Comment