Begin with the end in mind. – Stephen Covey
Too often, in packaged software implementations, we readily equate software features with business results. We declare success when software goes into production. We assume (or hope) that the packaged software will drive the desired business results. What we sometimes fail to realize is that software is only one component of a holistic solution that drives business results.
Another slippery slope we deal with during the implementation is the division of labor in order to accomplish project activities. We divide work based upon specialization. This leads to project members having ownership for a piece of the work and limits the project team's ability to validate that the desired business results are achieved. This division of work will also result in additional effort required to organize, direct, and control the work.
The implementation of packaged software is only part of the greater effort of creating a new business solution—an alignment of people, business processes, and technology to support and drive business results.
Challenging today's mindset
Before we can address the limitations of the traditional approach, we must first challenge our current thinking in regard to how we define project objectives, success measures, and scope.
We focus only on what we measure
How can one determine whether the project is focused on business results? I believe that what we measure is a good indicator of what we focus on. Consider the following measurement examples:
- Number of lines of code
- Project budget
- Project schedule
- Number of test defects
- Customer satisfaction
How do these metrics relate to achieving desired business results? I am not inferring that theses metrics are wrong, but what I am saying is that performance-related metrics focused on project execution should not be the only metrics that we utilize.
Project scope fixates on software features
Too often, I have observed packaged software implementations only focus on a subset of a business process, based upon the software features implemented. If you have a project that interacts with a business process then the implementation project needs to examine the entire business process to ensure that the desired business results are achieved. Otherwise, you assume that the upstream and downstream business activities will behave as they did before the packaged software implementation. What is more important to a business—installed software or reliable business results? I am persuaded to conclude that reliable business results are the focus of our customers. Now, let's spend a little time to address the main drivers for business results.
Focus on key drivers for business results
Let's briefly take a look at the key drivers for business results.
What is important to note here is that the implementation of a business solution not only considers packaged software but also the business processes and people that can have a greater impact on business results.
Technology is a great enabler that can play a role in generating business value. However, technology is not always the right approach to address problems inherent in a business model. Automation of a non-value-added business practice is not generating business value for the customer. "Making decisions and implementing them is where business value is created in an organization." Technology on its own does not have the capacity to consider a diverse range of issues and then act. Knowledge is an attribute of people—not software. Technology can store information, business rules, and other data that can facilitate the decision making process. From a knowledge management perspective, information only generates value for customers when information is applied and a decision is reached. "All of the work that goes into development is not adding value until the software is in the hands of the customer." It is people, not technology, that still make the business decisions that drive results.
Challenge to packaged software providers, and implementation partners
What are the strategic and tactical business decisions that your packaged software can support the customers in making? Leading packaged software providers and implementation partners should be able to provide this information up front to their customers. If the packaged software providers and/or implementation partners cannot provide these decision points then it begs the question of how well the provider/partner understands the underlying business model. If the software provider does not have a competent understanding of the underlying business model then the chances are that there will be significant gaps between the packaged software and your existing business model. Gaps always result in costing the customer money—either as software customizations or business process changes within your organization.
What results generate business value?
Early in my consulting career, I was native enough to assume that all business results generated by the customer's existing business model added value. I did not question the requirements defined in the customer's RFPs (Request for Proposals) and quickly proceeded to perform a ft/gap analysis. What I have learned from experience is that there are customer requirements that support non-value-added business activities and results. What I come to understand is that customer required can be based upon both needs and wants.
The traditional approach to requirements gathering and selection is reactive and full of non-value-added effort. The first step is to gather all requirements—regardless of whether a requirement generates real business value. The second step is to categorize and prioritize both the value-add and non-value-add business requirements. The third step is to perform an analysis on whether the packaged software can support the requirement. The final step is to conduct a formal ft/gap session to share the results of the first three steps and determine which requirements will be selected. There are three fundamental challenges with this approach:
- Wasted effort is spent gathering requirements that support no business value.
- It is easier to lose focus from the critical requirements that add significant business value. It increases the probability of missing value-added requirements due to a broader approach of capturing business needs and wants.
- It sets the stage for stressful ft/gap sessions with various stakeholders fighting for their requirements to be selected.
A better approach is to minimize or eliminate non-value-added requirements from being captured up-front. Challenging requirements can be adversarial for IT and implementation partners. It is almost impossible if one does not have a competent understanding of the business model. A practical approach that has worked well for me is to begin with identifying the desirable business results, and then drilling back to the business activities and the corresponding requirements that directly support the result.
We will use the above illustration to reinforce some concepts. First and foremost is that the customer's existing business model will have both value-added and non-value-added business activities that will drive business results. Also, consider that the existing model may have both desirable and undesirable business results. Performing this type of analysis will take two iterations:
- The first iteration defines all of the business activities and associates these activities with the business results that they support.
- The second iteration focuses on all of the business results and categorizes as value-added or non-value-added. This activity is then performed for the associated business activities.
By conducting this analysis the implementation team can lay the foundation to identify the business requirements that directly support desired business results.
How to focus on business results during an implementation
Now, it is time to turn our attention to practices that we can employ in order to better ensure that the packaged software implementation project focuses on business results.
Conduct business training
An undisputed implementation best practice is for the implementation team to take packaged software product training. I propose that another implementation best practice is for the implementation team to take training on the existing business processes that will be supported by the packaged software.
Understanding the business is the responsibility of every individual member on an implementation team. In fact, I would make it a prerequisite! Every individual project role will benefit from the training—including developers, software quality assurance, DBAs, data architects, implementation consultants, and especially project managers. Now, I am not saying that each individual needs to have the same business knowledge as the customer, but there is a basic level of business competency that each member should have. This training will enable a common language to be developed, and will improve collaboration.
We should speak in business terms and concepts and not technical jargon when interacting with customers. The responsibility of translation should be on IT and the implementation partners, who should translate technical and software-specific concepts into existing business terminology. This practice improves communication and enables quicker decisions to be extracted from the Business. I understand that the traditional role of a business analyst is to translate between Business and IT—but I fear this is being used more as a crutch and not to encourage every partner to evolve their understanding of the business that they support. There is no better real-time, practical method to align IT with the Business than speaking the language of the Business.
Implementation documentation should be Business-oriented
Data models, generally speaking, end up being not very helpful for understanding the business model. Data models have a limited place and impact. What documentation is more important to your customer—an Entity Relationship Diagram or a Business Process Map? IT and Implementation Partners should have an appreciation for both; however, both parties should strive for the greater understanding on the Business Process Map. Remember that the value of packaged business software is that it should not be necessary to redesign the software. If you have to redesign packaged software then you did not pick the correct software package. Having implementation documentation (forms and templates) geared towards business users will result in encouraging the project team to be business focused.
Use value-added Business results to filter requirements
Let's expand on our previous illustration that identified real business value.
In this illustration, we have business results that are driven by a series of business activities (i.e., business process). Now, we have included a series of business requirements that support the activities for a given business process. The final step of this analysis is to categorize the requirements based upon whether the requirement supports value-added activities or nonvalue-added activities. By focusing on the value-added requirements, we can proactively select requirements and accelerate the requirement-gathering activities. This exercise is not only useful to the implementation partner but also to the Business. It is an approach that can help the implementation team to justify why certain existing business activities are not being carried forward into in the new business solution.
Challenge to customers
Customers always ask what they can do to prepare for their packaged software implementation. Performing a business value analysis on their existing business processes is a key exercise that will help to further refine focus and ft analysis—more so than requirements prioritization. For five years, I supported accelerated implementation approaches and I have concluded that focus is the greatest enabler to rapid implementation.
Project objectives should address business results
Implementing packaged software is not a key business result in and of itself. However, I have observed that the majority of packaged software implementation project objectives are technology oriented. The project objective and scope defines project focus and success criteria. It is key that the project objective clearly address of all the components of a business solution and is business-results oriented. A basic project management principle states that the implementation project objectives and scope should align with the overall executive strategy for a customer.
Executive objectives are the highest-level goals for an organization. Business strategies are the high-level approaches to addressing the executive objectives. The project objective and scope are the corresponding tactical efforts required to support the business strategies. The implementation of packaged software is to support business results that satisfy executive objectives. A best implementation practice is to ensure that the project objective and scope can support meeting all of the expected business results by the packaged software implementation.
Before you can build a business solution, we must first understand the business, and the desired business results that generate real value for the customer. This is the first and most important step in implementing packaged software in such a way that we can provide maximum support to the customer's business value generation stream. Too often, Commercial Off the Shelf (COTS) software implementations focus on the individual functional pieces in silos and fail to validate that the end results—which are typically outside of the business software—generate the business value expected by the customer. Starting with the desired business results and working back to the value-added business activities that the packaged business software should support is an approach that will assist implementation teams in quickly focusing on what is important to the customer.
Alignment is key to being able to produce the desired business results. There are several key alignments that we need to develop and manage as part of the packaged software implementation. First is the alignment between the customer's executives and the project team with regard to project objectives and results. Second is the alignment between Technology (IT, Implementation Partner, Packaged Software Provider) and the Business with regard to the business model and the value-added business results. Third is the organizational alignment between the business model and the packaged software. These alignments cannot be one-time events, but must take place every day during the implementation project.