Solution designing is a crucial activity in any software project. Even when not much customization is involved, we still need to envision the "HOW" of the project.
"Do we really need a separate phase for designing the solution?" is an often-heard question. Some claim to initiate solution designing during the Analysis phase; others include it in the Development phase, or even "when convenient". From a waterfall perspective, you can plan your design activities in one or more phases as long as you execute what you planned for in a specific phase. So, there is no real waterfall reason for a specific Design phase. However, phases represent a breakdown in time, in order to plan and manage our project lifecycle better. That's why Sure Step plans for a separate Design phase with dominant solution designing processes. After capturing the scope baseline, we can now concentrate on further developing our solution concept during a well-managed timeframe. Most of us are familiar with the "what" and "how" rule of thumb: during the Diagnostic and Analysis phase we concentrate on the what aspect, whereas during the design phase we develop the how aspect of our project. This indicates what the dominant processes will be during those phases, but don't get mislead: project management and cross-phase processes have taught us that we need to plan for more in a phase than the core activities only.
The core activities of both Diagnostic and Analysis phases involve customer interaction by nature. Pre-sales activities such as requirements and business process assessments, proof of concept demonstrations, workshops, and interviews, among others require customer interactions. This is not so obvious during design and development activities. Design activities are commonly envisioned and narrowed down to documenting the how. This means designing equals writing documents on the how aspect, with the only planned customer interaction being the validation of the document. Combining this with the same passive vision on the Development phase will jeopardize our project success significantly, as we are factually locking out the customer from the project until the real deployment activities and postponing many of implementation activities. Do we really want to take that risk?
Start singing Sure Step's praises because it will release us from a passive Design phase. The real implementation activities start right here during the Design phase! Sure Step tells us not to wait until the end of the Development phase before initiating implementation activities. We need to maintain our contact with the customer organization by frequently interacting with the stakeholders. We need to raise the awareness and knowledge level of our stakeholders on the project and solution, stimulate organizational change, and continue risk and issue identification and management. There is so much to be done, and yes, we will also document some HOWs, but without limiting ourselves to this.
Now let's think about this for a minute. What does it say? It means that we are not delivering a pure development project. A bulk load of requirements can be fulfilled by installing standard features, configuring, or ISV solutions. Then why do we sometimes initiate the implementation only after finalizing the development activities? Some standard functionality will be dependent on the customized functionality, and these requirements cannot be implemented immediately, but this does not apply to all. One of the key advantages of a package solution is that we can deliver quite quickly compared to customized solutions. We need to take advantage of this by initiating the implementation as soon as possible. There is really no reason for postponing, we will benefit from the early delivery of even small parts of the solution.
During the Diagnostic phase, we gathered high-quality information, broken down into requirements, and mapped with our standard solution by categorizing into standard feature, configuration, customization, ISV solution, and workflow. We refined this understanding during the Analysis phase and rechecked it again with our standard product. This means we can start the Design phase based on structured information that will guide us on what to do next: implement and document.
The following diagram shows what to implement and document:
Coming out of the Diagnostic and Analysis phases, Sure Step does not bring in only the information, but also priorities, guidelines, conclusions, and a profound understanding of the to-be implemented solution. Standard features from the standard or ISV solution can be immediately implemented, along with the straightforward configuration requirements. Our implementation team must now start the engines and boost this project into warp drive. Some of the functionalities will have to wait to be installed or configured as they might depend on the customized functionalities. Do not panic about that; we can finalize the implementation later. The good news is that we have delivered part of the solution already, and the first customer complaining about that is still to be found!
Documentation is also part of the game. It is important to have a documented solution design, but we needn't include everything. We do not document the standard features but will concentrate on configuration settings and customized functionality. We use Functional Design Documents (FDD) to document our configuration and customization outlines. The configuration settings are to be documented in the FDD- FIT, while the customization is documented in the FDD-GAP.
Sure Step also provides a Technical Design Document (TDD), as well as a Solution Design Document (SDD). The TDD is a translation of the FDD-GAP in technical terms. The goal of this document is to define and document the technical details of each system modification or enhancement. This can be an essential component for the upcoming development activities when we are, for instance, working with junior developers or even in an offshore development context.
The purpose of the Solution Design Document is to allow the business decision makers and other stakeholders to obtain a clear view of the proposed solution design in business language. This can be a required document in companies with a high organizational complexity. Where the FDD documents are beneficial in all waterfall project types, the SDD is typically used in an Enterprise project type.
The application consultant will work hand-in-hand with the appropriate key user to implement and document. That's why at this stage, we should provide our key user with some training and coaching on the product's features and functions. This will not only bring our key user to the next level in knowledge of the product, but will also avoid misunderstandings and generate more commitment from the key user. Working closely with the key user will improve the collaboration for both teams, which is absolutely necessary for success.
Once we have implemented features and functions, we can unleash the power of a critical success factor in every project—testing. Testing will allow us to interact with the key users, identify issues, work and steer the perception, and update business process models. Initiating testing at this stage will also enable our key users to prepare for, organize, and take control over the user tests scheduled in the upcoming project phases. They can start their envisioning process of using the new solution right here. They will understand what testing involves and increase their product knowledge. Well-informed and committed key users are vitally important for project success, but we cannot expect that key users will reach our level of knowledge overnight. We need to make sure that they can build up their knowledge and understanding in small pieces so that they will be ready when needed. That's why we start here by initiating tests and test scripts in the Design phase. We will start with testing features and functions that we implemented together with the key user reinforced by the available Sure Step test scripts. After that, the key user can continue to prepare test scripts for upcoming tests.
Because of the starting of testing activities, we will have issues coming in as well. Again, embrace this, as it is an excellent opportunity to communicate and work around these issues and to plan for corrective actions. This is exactly what we want: revealing the issues so that we can overcome them instead of saving them for a later stage by not identifying them.
Installing and configuring the core product and organizing tests will also involve elements of the infrastructure, namely the test environment. This is a good opportunity to continue to interact with the infrastructure stakeholders. What is needed for all this? What do we need to do to convert the training into a real test environment? We can work hand in-hand with the infrastructure people, allowing them to get a better understanding of the infrastructural consequences of this new product; the interaction might reveal some new issues or risks as well. As you know, that is exactly what we want as it will allow corrective actions.
We need to continue our work on data migration that we started in the Analysis phase, by designing the migration process and mapping the fields to be migrated between existing legacy systems and the Microsoft Dynamics application. Because we initiate tests in the Design phase, we can create a subset of data for testing here as well.
A good project manager sees beyond today and knows that a well-organized Deployment phase is needed for a successful go-live. This project manager also knows that the success of the deployment depends on the commitment of the user organization. At the same time, we need to understand that our deployment activities will lay a heavy burden on that organization. Training, user acceptance tests, performance tests, and infrastructure readiness will demand a lot of their time and effort. We need to inform our customer about this and ask for their commitment and planning, and we need to do this well in advance. The Design phase is well chosen to initiate this. By now both teams have a very good understanding of what is to come, so we should tackle this right here. Sure Step provides us with a deployment plan that outlines the processes and activities that need to occur during the deployment phase of the project. It will ask for the customers' understanding and commitment for these activities. This is more than just scheduling the deployment. The Deployment plan must be an input for your communication around topics such as deployment scope, deployment strategy, deployment resources, training and testing organization, and the deployment schedule. Our goal is to get the customer's buy-in for the deployment activities. The bottom line is not just a document, but communication, communication, and again communication.