How to blueprint your project before the kickoff
You can imagine how difficult it will be to build a house without a blueprint. You won’t know what it is going to look like, how long it will take to build it, what resources you will need, and how much money it is going to cost you. I believe business application deployments are like building digital houses. You need to blueprint what you are going to build as the future solution before you start the process. In an earlier blog, I touched on how important it is to blueprint a solution prior to committing to a project (Please refer to this blog). Let’s dive into what this blueprinting exercise, sometimes referred to as diagnostics, entails.
There are four components to a good diagnostics exercise namely discovery, analysis, solution, and consensus. The length of the engagement changes based on the scope. The larger the scope, the longer the exercise. For a small CRM project for a single business unit in one location, diagnostics may be just a few weeks. A large global ERP deployment across several brands in several regions with different legacy systems may take several months. Regardless of the variation, each step in the process must be carefully completed to ensure an accurate blueprinting of the solution.
Diagnostics always start with discoveries. These are intense sessions that gather information and data about the business, systems, and processes. The focus is more about the future to-be state. The as-is is studied to identify the gaps. During discovery, business and system models - which were covered in earlier blogs (Please refer to this blog and this blog) are drawn and the processes are teased out. Discoveries should also identify the value proposition of the project.
The analysis is the study of these findings. Consultants need to analyze the business, systems, and processes to come up with a roadmap to take the company from as-is state to to-be state. They need to flush out what needs to be configured, what integrations must be written, what extensions must be coded, what data must be migrated, what report must be generated. This work may change based on the phasing strategy - which was covered in an earlier blog (Please refer to this blog). The value proposition can be also quantified at this stage.
The next step is studying different solutions to the problem. During solution sessions, different phasing approaches are studied. The list of configurations, extensions, integrations, migrations, and reporting is confirmed. A project plan is put together. The internal and external resource commitments are determined. These are then brought together to estimate the cost. The cost is then compared to the value proposition.
Consensus is the last but not the least step. All key stakeholders need to buy into the plan. Several presentations are made across different layers in the organization to drive consensus among business and IT people. The plan is scrutinized. Final adjustments are made. The return on investment is locked in. The documentation is completed.
I have personally conducted dozens of these exercises. They are intense engagements. Most customers love it. They can see why they are doing the project, where they are heading, and how they are going to execute clearly. That gives them the visibility and control they need to commit to the project.
If you are interested in learning more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
