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.
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.
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:
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.
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.
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.
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:
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:
By conducting this analysis the implementation team can lay the foundation to identify the business requirements that directly support desired business results.
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…