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.
