Category: Enterprise Software
Software Procurement on-time and on-budget
Are you asking the right questions?
So, you are looking for new enterprise or departmental software or some other type of major system. Maybe you are looking for a new ERP system, an EHR, a 311 system, or an EDMS? Maybe you need a major hardware upgrade as a solo project or as part of a new system project?
You might have already had discussions with vendors, or possibly you even know which product you want to purchase. Perhaps you are planning to purchase the ERP from TBQ International for manufacturing because that is what everyone in your industry uses and it seems like a safe bet. Or all of your neighboring Counties use O’Riley Technologies, so you think it will work for you. Maybe you called Bill, the Public Health Director from your neighboring County and he says Navajo Software makes a great EHR product and that is a good enough recommendation for you. You just want to get the project done.
The big problem with word-of-mouth recommendations is that YOU will be the one responsible for the success or failure of the project – the people who casually advised you will have amnesia about their recommendations if the project fails.
Regardless of where you are in the process, let’s step back and start over from the beginning.
60% of Projects Fail
According to the Project Management Institute, 60% of projects fail. Based on my own observations, the success rate for municipal software projects is probably lower than 40%. Government agencies rarely publicly or even privately admit that a project failed. Spectacular, expensive failures occur in the private sector as well, and the corporate landscape is littered with the carcasses of dead software projects where managers and executives have been forced into early retirement because of outrageous multi-million dollar cost overruns or outright failures.
Projects don’t succeed or fail by accident and you want to be overseeing one of the minority of projects that actually succeed. Whatever decision you make, your organization will be bearing the fruit of or suffering the consequences of your decision for the next 15 – 20 years, or longer. Large systems become a generational legacy, especially in the public sector. Regardless of the type of system you are seeking, the approach to purchasing the system should be the same. You need a rigorous methodology that incorporates staff buy-in and proven techniques for getting the features you need to make better business decisions. That system and the vendor’s culture must mesh successfully with your organizational culture. The vendor will be your business partner for the life of the product and thirty year old systems are not unusual in the public sector.
Why Projects Fail
Here are some common reasons why large software projects fail:
• Top Down management, planning and execution.
• Failure to identify and enumerate specific business goals and objectives.
• Failure to understand current, “as is” business processes.
• Failure to comprehend and plan for the entire scope of the project.
• Weak communication and stakeholder management.
• Failure to establish end-user buy-in.
• Failure to account for organizational culture.
• RFP doesn’t match your requirements for software and services.
• Underestimating the services required to configure the product.
• Underestimating or omitting training.
• Failure to plan for implementation.
• Insufficient or poor project and stakeholder management.
• Lack of Experience.
Over Budget!
I recently read a report written for a manufacturing organization written by a Big 4 consulting firm. The report was extolling the virtues of a top-down management approach to the company’s ERP project. The project was already over budget by $15 Million and the meter was still ticking. I suppose the consulting firm was scrambling for excuses for their disastrous management of a project that will eventually come in 300% – 500% over budget.
I couldn’t disagree more with the Big 4 firm when it comes to top-down management of large projects.
Inside-Out Management
You can’t build airplanes in the air and you don’t build a pyramid starting from the top. Large software procurement and implementation projects must be built from the ground up with a strong foundation that results from giving the stakeholders who will actually be using the system a prominent seat at the table. Yes, you need strong executive support for a major software/business reengineering project, but executives may never use the system. If you don’t build a robust foundation provided by the people who actually understand the granular level of all the organizational business processes, the project will be difficult, seriously over budget, or may fail completely. Succeeding at these types of project requires top-down, bottom-up, and inside-out management. You must examine every aspect from every angle.
Lack of Experience
Lack of experience is another major reason why large system projects fail. Large system procurement and implementation projects are events that occur only once or twice in the career of many employees in the public sector. If you are an executive in a very large public sector organization, you may have full-time professionals who specialize in software procurement and implementation projects. However, there are 3033 County governments in the United States, over 19,000 municipal governments, and nearly 14,000 independent school districts. The vast majority of these organizations cannot afford to employ experienced full-time system procurement and project specialists. If you are an executive in this real world of municipal government, what do you do?
The Role of Organizational Culture
Even when expert, internal resources are available, there may be cultural issues in organizations that can make projects involving significant change impossible. I once worked on a project for a Fortune 100 company that employed a large staff of professionals who could theoretically have performed the large migration project they were undertaking. However, their institutional culture made it impossible for them to complete the project. The ultra-stratified management structure and extreme risk aversion made the execution of such a project impossible for them to implement internally and they had to contract a small army of risk-tolerant consultants to do the work.
RFP’s From the Internet
Unfortunately, many organizations begin the process of software procurement with an RFP. Even worse, they sometimes use an RFP that was downloaded from the Internet and written for another organization with different requirements, different business processes and an entirely different organizational culture. The truth is, the same piece of software that works for your neighboring county, school or city may not work for you. There are hundreds of commercially available ERP products for municipal governments. When you factor in Utility Systems, Public Safety Systems, Records Management Systems, Tax Collections Systems, Traffic Management Systems, Public Health Systems, Code Enforcement Systems, and the like, there are thousands of products from which to choose. How do you navigate such a massive set of choices?
The Solution
Following a rigorous and disciplined methodology for the procurement process will vastly increase the probability of a successful outcome. Maybe you already have a system that works well. Below is a summary outline of the system I have used and honed since my first large software procurement in 1996. If you are experienced at software procurement and implementation projects, this information may seem to be self-evident. However, considering the number of failed municipal software projects I have seen, the message hasn’t really gotten out yet. Notice that the RFP finally comes up in Step 8.
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or RFB (Request for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Site Visits – Customer and Vendor HQ
- Hold Software Demonstrations & Select a Solution
- Negotiate and execute the Contract
One of the primary objectives should always be the improvement of the quality of services in your organization and you should be aware of some of the project risks and political ramifications.
I cover the entire process here. Please feel free to e-mail me if you have comments or want to discuss software procurement in your organization. If you take a sensible and cautious approach using all due diligence, your project will certainly be a success.
If you want to talk about your project, send me an e-mail at jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2015, 2018
by 
Choosing a Behavioral Health EHR System
As a Mental Health Commissioner or Director of Community Services, purchasing the right EHR & Practice Management System will be one of the most important business decisions of your career. Even for a relatively small practice, you will spend at least several hundred thousand dollars once all the relevant modules, training, data migration, and implementation are accounted for. It’s an overwhelming decision on top of DSRIP, ACA and all the other changes in the industry.
One of the big problems with purchasing such a system is the learning curve. If you are new to the procurement of major systems, you probably don’t have all the tools you need to get through the process. The second problem is all about assumptions. Managers who are new to software procurement often make the assumption that the software company is providing a turnkey solution. Here is the ugly truth: the software company will only do exactly what you asked for in the RFP. Anything you forgot will cost extra. Even if you are purchasing a turnkey solution, there is still a great deal of work for you and your staff to do. Here is a link to my article about software implementation models.
First, let’s talk about some of the tools you will need as well as the general approach to the procurement process you should be taking. Then, we’ll discuss some of the specifics for EHR/Practice Management systems.
The 12 Step Program for Software Procurement
I have written about this before in other contexts, but the basic process is the same whether you are purchasing an ERP, EHR, CRM, or any other type of system. Following is a summary of the basic steps with links to more detailed discussions of the specific steps.
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or IFB (Invitation for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Hold Software Demonstrations & Select a Solution
- Customer and Vendor Site Visits
- Negotiate and execute the Contract
You may have noticed that drafting and issuing an RFP comes late in the project. In many of the failed projects I have studied and reviewed, the buyer treated the RFP as the first step rather than one of the final steps. Moreover, I have presented the steps sequentially, but they don’t need to be so. For instance, steps 3-7 can be conducted concurrently if you have a staff member or consultant with the skills to do so.
It sounds like a simple process, and it is. It’s going to take more than 15 minutes to put it together, however. If you are truly using due diligence, it may take several weeks to gather all the information required to assemble your RFP.
Behavioral Health Specific Questions – Some Considerations
In addition the procedures described above, there many industry specific factors to consider. I provide a summary of some of these issues below in the form of questions. However, this is not intended to be an exhaustive discussion. Please e-mail me if you wish to discuss your project in more detail and we can setup an appointment to talk. The first hour is free!
Meaningful Use
Are the systems you are reviewing certified for all 3 stages of Meaningful Use?
Forms & Regulatory Compliance
What forms do you currently use? Are your forms fully compliant with both Medicaid and NYSCRI or other state specific forms? Does the vendor have a major presence in your state and are they committed to the immediate implementation of regulatory changes for your state? Will there be an extra charge for unexpected regulatory changes? Will you require custom forms with custom mandatory fields?
HL7 and Interoperability
Do you need RHIO connectivity? Right now or down the road? What sort of impact will DSRIP have on your project?
Third Party Hardware and Software
What third party hardware and software is required for the system? How much does it cost and what will be the 5 year TCO?
Document Management
Will the system allow you to go paperless? What about the cost of scanners? Will you use a centralized or distributed model for document imaging? What are your state’s regulatory requirements for scanning? Most states have specific legal and procedural requirements for document imaging. For New York, the requirements can be found here. Is your software in compliance with state imaging guidelines?
Workflow
What is your workflow from initial client contact forward? Every agency has a different workflow and quality EHR systems have flexible workflows that can be adapted for your specific requirements. Do you have flowcharts? Do you want to change your workflow to a more efficient model during implementation? What will your new workflow look like? Who is going to configure rules and alerts for Treatment Plans, etc? What is the workflow between clinician and billing?
Total Cost of Ownership (TCO)
What is the real 5 year TCO of your system including maintenance, support, consulting services, implementation and third part products?
Return on Investment (ROI)
What will the ROI of your system be? Will productivity improvements allow you to reduce staff or will you have to add staff?
SaaS Vs. Customer Hosted
Do you have the infrastructure to host the system internally? Or does a SaaS (aka “Cloud”) system make more sense? Which makes more sense from a business perspective and what are the long term costs and consequences of each type of system? What are the pros and cons of each system?
HIPAA
Do you have a Comprehensive Information Security Policy? Is the software you are purchasing flexible enough to implement your security policy in the system? Do you have an information security officer? Who will monitor and document system security?
Reports
What are your reporting requirements? Will you staff need special training to build reports? Have you included required reports in the RFP? Does the software allow you to easily build required CFR’s?
Data Migration
Who is going to handle the data migration? Most vendors insist that you supply the data to them in a specific format. Do you have staff members who can extract the data from your old system and provide it to the vendor in the requested format? Who is going to validate the migrated data and how long will it take?
Payors
Do you have a comprehensive list of Payors and Clearing Houses? Each of these will have to be configured individually. How will your system handle write downs? Cash Payments? Credit Cards? Invoicing? Are you still doing any paper billing or is it all electronic? What billing forms do you use and are all these supported by the system?
Installation, Implementation, Configuration
Have you budgeted for sufficient professional services to get the project completed without excessive cost overruns? Are you going to implement EHR and Billing simultaneously? Or in stages? What is your timeline?
Training
Have you budgeted for sufficient training and Go Live support? No matter how much training you have built into the project, I assure you that you will need more than you think.
Change Management
I get it. You are Mental Health Professionals, but transition to a new EHR/Practice Management System is a painful process and Change Management is something that must be considered.
The RFP
You may wish to read my article on writing RFP’s before you get too far down that road.
Summary
EHR/Practice Management projects are only successful when the executives provide unwavering support and dedication. These sorts of projects don’t succeed or fail by accident. You will have to roll up your sleeves and get your hands dirty to succeed with the minimum amount of pain.
As I have already indicated, this is a partial list of questions you should be considering before you write an RFP. Please e-mail me at jmorgan@e-volvellc.com if you would like to discuss your EHR or Practice Management System Requirements.
by A 12 Step Program for ERP Procurement
Procuring and implementing an ERP is like driving down a winding country road on a stormy night. You can’t see clearly through the fog and rain and you aren’t sure if you are headed in the right direction. Google Maps doesn’t have a route.
A good set of directions will get you to your destination, though. Following a rigorous methodology can reduce the anxiety and will vastly increase the probability of a successful outcome.
Following is a summary of the steps to take to ensure you have a successful ERP (or any other) software procurement project.
The 12 Steps to ERP Procurement
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or IFB (Invitation for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Hold Software Demonstrations & Select a Solution
- Customer and Vendor Site Visits
- Negotiate and execute the Contract
Easy, right? Only 12 steps and you will have a business process face lift along with software that works effectively for your organization.
RFP is not the First Step!
You may have noticed that drafting and issuing an RFP comes late in the project. In many of the failed projects I have studied and reviewed, the buyer treated the RFP as the first step rather than one of the final steps. Moreover, I have presented the steps sequentially, but they don’t need to be so. For instance, steps 3-7 can be conducted concurrently if you have a staff member or consultant with the skills to do so.
Don’t let your ERP procurement project drive you to drink! Make a road map, follow it diligently, and you will surely arrive at your destination on time. You can read a more detailed description of the process of getting started, here.
Read more about IT Governance, ERP Prcocurement, Enterprise Software and other related issues at http://blog.e-volvellc.com. Feel free to e-mail me at jmorgan@e-volvellc.com if you would like to discuss your project.
by Swiping Municipal RFP’s from the Internet
RFP’s Are Not Universal
RFP’s aren’t universal but County and Municipal governments frequently use another entity’s RFP in the procurement process rather than writing their own. I suppose the motivation is to save money but the probable outcome of this practice is more likely to result in a large financial loss or a difficult implementation.
I know of at least one case where an RFP that I wrote for a very successful project was “borrowed” by another County that ended up having a difficult time with their project. This is no mystery to me. I spent a great deal of time analyzing my client’s workflow, business processes, and organizational culture before writing their RFP. The other County apparently didn’t think any of these aspects would make a difference and focused on the technical specifications that I developed. However, technical specifications are only a small part of an RFP, and probably not the most important component. There are many other factors to consider.
There is nothing ethically wrong with editing and re-releasing another County’s RFP. After all, it’s a public document and no one owns the copyright. However, from a business perspective, this is a terrible practice that could result in an organization procuring a product that is totally wrong for them. Let’s take a look at two different Counties and then talk about some of the problem with swiping RFP’s from your neighbors.
Case Study: A Tale of Two Counties
Flower County
Flower County and Rock County are adjacent to each other and it is only 40 miles from one County seat to the other. Both Counties have a population of 100,000. Flower County has a large university, a community college and a significant urban center in which most of the county population lives. The County Commission is composed largely of university professors, corporate managers and retired public servants. Residents of Flower County are proud of the plethora of government services they offer to their residents. The Flower County Executive is a career public service professional with a Master’s in Public Administration and the County maintains a large Information Technology department, the members of which are all CSEA members. They have developed an extravagant, high bandwidth Information Technology infrastructure that connects all their buildings.
Rock County
Rock County is managed by a successful, retired entrepreneur. The County is decentralized, rural and has no institutions of higher learning. In Rock County, the County Commission is composed of farmers and small business owners. Residents of Rock County are extremely proud of their low taxes and are committed to maintaining a small, efficient government that provides mandated services with no frills. The County has no Information Technology department and contracts all the required services through professional services firms. Rock County has a very basic IT infrastructure with low bandwidth connectivity between buildings.
Both Counties are seeking a new ERP system. Rock County is interested in highly automated systems so they can eliminate FTE’s involved in processing financial transactions and are open to contracting as many services as possible. Flower County wants to further expand the online services available to the Community and they are willing to add FTE’s to achieve their goals. Both of these communities have the same requirements for producing federal and state financial reports and for managing their respective budgets. That’s about all they have in common.
Both Counties have committed to a budget of $1,000,000 for their software and implementation and they can both realistically achieve their goals. Is it likely these counties will choose the same vendor and suite of products to manage their finances? Maybe, but the probability is low. If these Counties use a rigorous procurement process, their RFP’s are going to be very different. Even if they do purchase the same product, the implementation of that product is going to look very different.
Let’s Call Another County and ask them!
In County and Municipal government, one of the common “techniques” for software procurement and getting questions about business processes answered is to call up another County or City and ask how they do it. Following the pack is a popular approach. But, what if the other County or City is doing it wrong, doing it poorly or doing it inefficiently? Or, what if there are so many business and cultural differences, as in the case study above, that the other entity’s approach is just wrong for your organization?
Organizational Culture Matters
The appetite for change and internal politics in an organization can have a significant impact on the success of a project and I have written about this here. I always include a frank description of organizational culture in my RFP’s so the potential vendors have some idea of what they are getting into. If you want a project to be successful, you must account for the way your staff will behave and react during implementation. If your staff is composed of fifty-somethings who have done the same jobs for 30 years, they will certainly react in a completely different manner than twenty-somethings who are newer to their professions. Is your staff flexible or rigid? Are they open to new ideas and processes?
The skill level of your staff is also another consideration. What kind of implementation approach will be successful in your organization? An implementation approach that works for one County may not work for another and taking a cookie cutter approach is likely to create significant cost overruns.
Workflow and Business Processes Matter
A thorough Business Process Assessment is essential for a successful project. After 23 years of working with County and Municipal agencies, I have learned that everyone does it a little different. Workflow is important to consider as well. Is the vendor’s workflow flexible or is it canned? If it is flexible, how hard is it to adjust? Is your current workflow streamlined or Byzantine?
While Rock and Flower County may find different solutions to address their business requirements, the approach they take to arriving at that solution should be the same and you can read about it here.
Just Stop It!
I hope this brief discussion clearly illustrates why copying an RFP from the Internet, or basing your purchasing decision on a neighboring County’s recommendation are not sound business approaches to software procurement. Flower and Rock County are seeking to purchase an ERP solution, but they have different business goals and objectives and very different cultures. There is a high probability that these counties will make different decisions if they use a thoughtful, rigorous approach to procurement.
If you would like to discuss the development of custom RFP’s that will work for your organization, please feel free to e-mail me. Let’s talk! And for heaven’s sake, stop copying RFP’s. Write the custom RFP you deserve or contract someone to do it for you. It will save you both money and many headaches.
Copyright © Jeffrey Morgan 2016
by Homegrown Software in Municipal Organizations
Homegrown Software?
Should software development be a core business function in your municipal or county government operation?
Does your organization build its own cars, trucks and buses? Do you make your own office furniture internally because it has to be really special? Do you manufacture your own pens, pencils and computers? Then, why on earth would you write your own software?
A Brief History of Municipal Software
In the olden days of MIS (Management Information Systems), many MIS people understood business systems, especially finance and accounting systems and knew how to build them from the ground up. There wasn’t a great deal of commercially available software and even when there was, it ran on a mainframe or mid-range system like a System 36, AS400, MicroVax or UNIX system that required expert maintenance. Building business systems was part of MIS training and knowledge. This is no longer true. Younger generations of IT people (MIS people are retiring in droves) are trained to build and support modular infrastructure systems, but not to build business systems like financial accounting software from scratch. Extensive training in business processes is no longer part of the education of the average IT employee. Yes – there are exceptions and I am sure you can show me those.
Commercial Software
In the county, municipal and K-12 markets, someone has developed a commercial software application for just about every business process and function you might require. It’s a big market with 59,000 potential commercial customers. If you are for some reason considering custom or internally written software, I would like to ask you a question: What is so different, unique and special about your organization that you need something that none of the other counties, municipalities and schools in the country need? Maybe you can surprise me and show me the business case, but I doubt it. The need for custom software should be rare these days.
We Are Special!
Maybe your programmers or end-users insist that no commercial software can work with your unique business processes because you are the only municipality in the world that sends out sewer bills your special way. If that is the case, you should be asking why your business processes are so different from the rest of the world that you would need custom software written internally.
Continuing the Legacy
If you do have a programming staff, there is a good chance their primary job is to provide life support and intensive care for your homegrown legacy system that was written decades ago. While the programmers were at it, they probably kept developing other custom programs to justify their jobs. If this is the case, you may have a huge jumble of poorly documented and inefficient software that requires constant care and feeding. Some of it probably isn’t even being used and the software may not be able to compete with what is available in today’s market. Start planning now to make an orderly exit from the homegrown software business. It may take several years, but it is worth the effort.
What is the TCO and ROI of Homegrown Software?
Let’s take a look at the cost of an in-house programming staff for a mid-size County with 6 programmers.
I’m being really conservative here and this is a very simplistic model, but it demonstrates the reality of your in-house software production. All of the variables for your situation may be different and your programming staff may be smaller or larger. However, you can buy a lot of commercial software for $800,000.00 a year! Moreover, the annual support cost for commercial software in subsequent years may be in the vicinity of $150,000 with commercial software, so you will be saving over $600,000 a year after year one. Forever! You could do a lot with that money. While your case may require much more complex calculations, the bottom line will be the same: your in-house programming staff is costing you serious money and possibly not delivering ROI that is consistent with the cost.
Hidden Costs & No Economy of Scale
There is another cost of custom or in-house software that is not easily represented in terms of dollars. That is the cost of a product written for a single customer with no economies of scale. Commercial software that has hundreds or thousands of installations has been vetted nationally and programming mistakes are found quickly. Software products used only by one customer often have errors that are not identified for years or decades, if ever. I have seen examples where reports were wrong for years, tax bills that went out for years with mistakes, etc. Once discovered, these mistakes could cost you millions if you have to provide refunds or end up in litigation as a result. Or, you may have lost millions of dollars in revenue because you have been undercharging due to programming mistakes.
We’ll market and sell it!
I have heard this proposed more than once – municipal employees suggesting they develop a software product and then sell it to other municipalities in order to recoup the development costs and make a profit. Those are twilight zone moments for me and it takes a few minutes to recover from the shock. While I am recovering, I am hoping the Mothership will beam me up before I have to craft a diplomatic response. They have no idea of what is involved in developing, testing, debugging, marketing, selling and supporting a commercial software product. Stick to your core business of delivering government services and do it well.
Just Say NO to In-House Programming
There are cases for which custom software is appropriate and if that is your case there are outstanding custom programmers available who can fulfill those needs. Contracting programming services is generally a better business decision than maintaining a permanent in-house programming staff unless you have a really large operation. If the job is done right, it will only need to be done once.
Don’t get involved with in-house programming if any other option is available. And there are almost certainly other options available. You always have a choice and this is a choice about making a good business decision. Get out of the custom software business and buy off-the-shelf products with long-term, expert support contracts.
by Introduction to Enterprise Procurement Projects – Part 3 – The Business Process Assessment
What is a Business Process Assessment?
Now that you have established preliminary Goals, Objectives and Criteria for Success for your enterprise project, it is essential to conduct a Business Process Assessment to identify the actual business practices in your organization. When I refer to a Business Process Assessment, I am talking about a comprehensive, objective, and assumption-free evaluation of all the activities, processes, procedures and personnel involved in the production of a specific product such as a payroll run, an accounts payable run, or an AR billing cycle, to name just a few.
An Example
Let’s use payroll as an example. An appropriate assessment might begin with a new pay period and should include the examination of all the tasks, steps, people, processes, procedures and paperwork involved in payroll production. How do departments report time to the payroll office? Is it paper based or automated? How much does it cost your organization to produce a payroll check? How many people are involved? How is the payroll produced? Is all the work done in a single system? Are there spreadsheets and exceptions involved? What reports are produced monthly, quarterly, annually? Are there bottlenecks? Excessive mistakes? Recurring problems? Regulatory compliance issues? Problem departments? Problem people?
Do you really know what your process are?
You might think you already know all this and you feel you have a solid understanding of how all your departments conduct business. It is often the case at this stage that executives and managers explain to me what they truly believe to be their business practices and processes. These descriptions are frequently completely wrong.
It is difficult to evaluate new systems if you don’t truly understand your current systems. With systems and staff members that have been running unchallenged and unchanged for decades, staff members, supervisors and managers often perform tasks without questioning the underlying processes. A thorough Business Process Assessment identifies and documents all these processes and establishes a baseline for your current business performance.
Getting Started
Surveys, either paper-based or electronic are a good tool with which to begin but they are no substitute for direct observation and interviewing staff in each department. One possible approach to conducting a system-wide assessment might be to disseminate surveys first and then conduct department level interviews as the next step.
The final product of the Business Process Assessment should be a detailed report describing current, identified practices, processes and problems. This report should also include suggestions and recommendations for improving the processes going forward.
You may find it difficult to perform an accurate assessment using internal staff. Regardless of how well-intentioned, smart and motivated they are, organizational culture, biases, and assumptions are likely to be an obstacle and the objectivity may suffer. If you would like to discuss any aspects of your Business Process Assessment, or any other part of your enterprise project, send me an e-mail at jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2016
by Introduction to Enterprise Procurement Projects Part 2 – Establishing Goals and Objectives
Establishing Goals, Objectives, and Criteria for Success may be the most the most important component of your project. How will you determine whether or not the project is successful if you don’t clearly plan for and enumerate your goals? Your Enterprise Project may be an undertaking that requires several years from inception to completion. Management and staff have often lost sight of the original goals by the time they reach the finish line, so document and update goals clearly throughout the project.
We want the goals to be clear and measurable. Some popular goals include “improving efficiency” and “reducing operational costs.” These sound good but you must be more specific. What does improving efficiency mean to you? Do you plan to process more work with the same staff? Do you plan to eliminate FTE’s as part of the project? By attrition or not? Does this project represent a completely new undertaking or are you just re-engineering current processes?
There are many ways to approach the establishment of goals and objectives and I will discuss two possible methods here. Only one of these methods actually delivers consistent results. Before discussing these two methods, I first want to discuss the way some (many?) managers and organizations approach enterprise projects.
The Shotgun Approach
The most commonly used approach to Enterprise Projects I have observed in organizations is what I call the Shotgun Approach – shooting software and technology at a problem in the hope that the software will solve whatever business problems the organization is experiencing. In these cases, software is purchased without much thought and without any significant goal setting, analysis, change management, or input from end users and stakeholders. Sometimes, the goals are vague, such as “implement a new payroll system.” With the Shotgun Approach, the management often purchases a solution without consulting the staff and without studying and documenting the current business processes in order to understand the root cause of problems, errors, poor quality, and excessive costs. Sometimes these decisions are based on price or product reputation alone without consideration of other essential factors.
If you get lucky, the Shotgun Approach might create some improvements, but I have also seen it backfire completely. I worked for one organization where the management tried this approach to implementing a new payroll system and it turned out to be an utter disaster. This was a case where the management didn’t consult any appropriate and available resources about the wisdom of their plan. A few meetings with the appropriate stakeholders and Subject Matter Experts would have prevented a year-long, painful and expensive implementation that was ultimately scrapped. The six-figure loss to the organization was relatively inexpensive as far as failed software projects are concerned. However, the damage to morale and the management’s total loss of face were more damaging than the monetary loss.
Setting Specific Numeric Targets
Some managers would take an approach based on reaching specific targets such as: “20% reduction in FTE’s” or “a 10% reduction in in operational costs.” These are laudable, measurable, and specific goals, so they seem on the surface to be what we want. While this type of approach has many merits, it is not optimal and I will explain why.
If you are building a new system, or are replacing an old one, some aspects of the new system will be unknown and unknowable (W.E. Deming, Out of the Crisis). It is possible you have some methodology for calculating some of the business variables, like staffing or maybe you are creating arbitrary targets. An infamous piece of Federal legislation is currently taking the Arbitrary Target approach by creating the goal of a 25% reduction in Medicaid hospital admissions. Tens of billions of dollars will be spent pursuing this dubious target with no credible evidence that the proposed processes will work. The likely result of this program will be perverse incentives that exacerbate the current problem and will create new problems in the future.
In some cases, numeric targets are possible and desirable. For instance, if your organization has homegrown software supported by an in-house programming staff, the purchase of Commercial-off-the-Shelf (COTS) software may entirely eliminate the need for the programming staff. In this case, it would be reasonable to set a numeric target for the elimination of the staff members in question or they could alternately be reassigned to other critical organizational tasks. The unknowable portion of this example might be the resources required to support the new system, if any.
I am not implying that just because something is unknown that you shouldn’t make a plan – just write the plan in pencil. There are other knowable elements as well.
In one organization I worked with, the payroll department was spending two days per payroll period (over a period of decades!) making manual calculations in spreadsheets. They weren’t using their ERP fully because it was not performing the calculations correctly. Rather than insisting that the software vendor correct the problem, the staff permanently enshrined the workaround as part of their business process wasting at least 20% of an FTE. So, this is another case where a numeric target is knowable and therefore acceptable. Using a fully automated system with correct deduction tables and time and attendance entry at the department level, it might be realistic to expect a 30%+ increase in productivity surrounding payroll production.
In this case, another goal to strive for should be error-free payroll production. Redoing work as a result of mistakes is expensive. In order to achieve this goal, all of the processes must be examined carefully in order to identify the root cause of errors.
Other goals might include the elimination of duplicate data entry and spreadsheets by distributing time and attendance entry to individual departments if your system is currently centralized.
Improving Quality of Processes, Products or Services
In my experience, Enterprise or Departmental projects with the most successful outcomes have been those undertaken by management whose primary objective was improving quality. Generally, if you focus on improving quality, many problems like duplicate data entry and excessive personnel costs will automatically sort themselves out. Solution for other problems will become apparent during this undertaking, especially if you are committed to a cycle of continuous improvement.
One of the best real-world examples I can think of as evidence for quality improvement as the primary objective is a manager I worked with a few years ago. She was completely committed to implementation of processes, policies, and procedures that improved the quality of services in her organization. New software was part of the equation and many of the processes, policies and procedures were built into the new software system. No specific numeric targets were set in advance, but there was a general understanding that the number of FTE’s for processing of data and transactions would go down. As a result, she realized a significant increase in revenue along with a 36% reduction in staff as well as a measurable increase in productivity. Focusing on quality works fantastically well.
Summary
When developing goals and objectives, focus first on Quality Improvement and use a cycle of continuous improvement. Let’s take a look at what your goals and objectives might look like using the examples previously discussed.
Objective: Improve the quality and efficiency of Payroll Production.
Goals:
- Identify and correct processes and procedures that create errors and hinder productivity.
- Fully document best practices, processes and procedures going forward.
- Eliminate the use of Spreadsheets in payroll production.
- Achieve error free payroll runs.
- Distribute Time and Attendance entry to the department level.
- Improve the productivity of payroll staff by 30%.
- Eliminate or reassign programming staff involved with payroll production.
As you are following subsequent steps in the procurement process, the details of your goals and objectives are likely to change but the overarching objective of improving quality should remain the same. The process of discovery that you undertake next will reveal many details about your operations that you will want to change.
If you would like to discuss setting appropriate goals and objectives for your enterprise project, e-mail me at jmorgan@e-volvellc.com and I will be happy to discuss your specific case.
Copyright © Jeffrey Morgan 2015
by Business Santa Claus
By Jeffrey Morgan
It is fun to pretend there is a Santa Claus when your children are young. Even the most curmudgeonly person can get a warm feeling from the jubilant innocence and wonder shining out of those big eyes at the thought of Santa Claus.
I have observed many adults who believe in Santa too. I am always amazed by the hard-nosed, otherwise intelligent business people who still believe in free stuff. Business Santa is even more amazing because he brings free stuff all year long! He might pop in with free e-mail, free websites, free software, and free consulting services at any time. And free stuff is always the best stuff in some people’s minds.
Free is usually the most expensive product or service you can buy, or at least that has been my observation over the last twenty two years. If you are getting a product or service for free, you are the product that is being marketed, packaged and sold. Moreover, while the product or service might be free, implementation and support are not. And you might have to redo all that work again if the free product doesn’t work out.
So, beware of free stuff. If you do take advantage of free products or services, make sure you read and understand the license agreement thoroughly and make sure you understand what the Total Cost of Ownership (TCO) is. It is not likely to be free, but sometimes it is hard to figure out what the catch is. What is the motivation to give you something free?
I don’t want to confuse free software with Open Source software. That is a different animal completely, but comes with its own hidden costs, but we will talk about that in another post.
As always, if you need help evaluating the cost of free products, send me an e-mail at jmorgan@e-volvellc.com. I’m not free, but I might help you save some money. And don’t forget to leave cookies and eggnog for Santa.
Copyright © Jeffrey Morgan 2015
by Enterprise Software – on time and on budget
Are you asking the wrong questions?
So, you are looking for new enterprise or departmental software or some other type of major system. Maybe you are looking for a new ERP system, an EHR, a 311 system, or an EDMS? Maybe you need a major hardware upgrade as a solo project or as part of a new system project?
You might have already had discussions with vendors, or possibly you even know which product you want to purchase. Perhaps you are planning to purchase the ERP from TBQ International for manufacturing because that is what everyone in your industry uses and it seems like a safe bet. Or all of your neighboring Counties use O’Riley Technologies, so you think it will work for you. Maybe you called Bill, the Public Health Director from your neighboring County and he says Navajo Software makes a great EHR product and that is a good enough recommendation for you. You just want to get the project done.
The big problem with word-of-mouth recommendations is that YOU will be the one responsible for the success or failure of the project – the people who casually advised you will have amnesia about their recommendations if the project fails.
Regardless of where you are in the process, let’s step back and start over from the beginning.
60% of Projects Fail
According to the Project Management Institute, 60% of projects fail. Based on my own observations, the success rate for municipal software projects is probably lower than 40%. Government agencies rarely publicly or even privately admit that a project failed. Spectacular, expensive failures occur in the private sector as well, and the corporate landscape is littered with the carcasses of dead software projects where managers and executives have been forced into early retirement because of outrageous multi-million dollar cost overruns or outright failures.
Projects don’t succeed or fail by accident and you want to be overseeing one of the minority of projects that actually succeed. Whatever decision you make, your organization will be bearing the fruit of or suffering the consequences of your decision for the next 15 – 20 years, or longer. Large systems become a generational legacy, especially in the public sector. Regardless of the type of system you are seeking, the approach to purchasing the system should be the same. You need a rigorous methodology that incorporates staff buy-in and proven techniques for getting the features you need to make better business decisions. That system and the vendor’s culture must mesh successfully with your organizational culture. The vendor will be your business partner for the life of the product and thirty year old systems are not unusual in the public sector.
Why Projects Fail
Here are some common reasons why large software projects fail:
• Top Down management, planning and execution.
• Failure to identify and enumerate specific business goals and objectives.
• Failure to understand current, “as is” business processes.
• Failure to comprehend and plan for the entire scope of the project.
• Weak communication and stakeholder management.
• Failure to establish end-user buy-in.
• Failure to account for organizational culture.
• RFP doesn’t match your requirements for software and services.
• Underestimating the services required to configure the product.
• Underestimating or omitting training.
• Failure to plan for implementation.
• Insufficient or poor project and stakeholder management.
• Lack of Experience.
Over Budget!
I recently read a report written for a manufacturing organization written by a Big 4 consulting firm. The report was extolling the virtues of a top-down management approach to the company’s ERP project. The project was already over budget by $15 Million and the meter was still ticking. I suppose the consulting firm was scrambling for excuses for their disastrous management of a project that will eventually come in 300% – 500% over budget.
I couldn’t disagree more with the Big 4 firm when it comes to top-down management of large projects.
Inside-Out Management
You can’t build airplanes in the air and you don’t build a pyramid starting from the top. Large software procurement and implementation projects must be built from the ground up with a strong foundation that results from giving the stakeholders who will actually be using the system a prominent seat at the table. Yes, you need strong executive support for a major software/business reengineering project, but executives may never use the system. If you don’t build a robust foundation provided by the people who actually understand the granular level of all the organizational business processes, the project will be difficult, seriously over budget, or may fail completely. Succeeding at these types of project requires top-down, bottom-up, and inside-out management. You must examine every aspect from every angle.
Lack of Experience
Lack of experience is another major reason why large system projects fail. Large system procurement and implementation projects are events that occur only once or twice in the career of many employees in the public sector. If you are an executive in a very large public sector organization, you may have full-time professionals who specialize in software procurement and implementation projects. However, there are 3033 County governments in the United States, over 19,000 municipal governments, and nearly 14,000 independent school districts. The vast majority of these organizations cannot afford to employ experienced full-time system procurement and project specialists. If you are an executive in this real world of municipal government, what do you do?
The Role of Organizational Culture
Even when expert, internal resources are available, there may be cultural issues in organizations that can make projects involving significant change impossible. I once worked on a project for a Fortune 100 company that employed a large staff of professionals who could theoretically have performed the large migration project they were undertaking. However, their institutional culture made it impossible for them to complete the project. The ultra-stratified management structure and extreme risk aversion made the execution of such a project impossible for them to implement internally and they had to contract a small army of risk-tolerant consultants to do the work.
RFP’s From the Internet
Unfortunately, many organizations begin the process of software procurement with an RFP. Even worse, they sometimes use an RFP that was downloaded from the Internet and written for another organization with different requirements, different business processes and an entirely different organizational culture. The truth is, the same piece of software that works for your neighboring county, school or city may not work for you. There are hundreds of commercially available ERP products for municipal governments. When you factor in Utility Systems, Public Safety Systems, Records Management Systems, Tax Collections Systems, Traffic Management Systems, Public Health Systems, Code Enforcement Systems, and the like, there are thousands of products from which to choose. How do you navigate such a massive set of choices?
The Solution
Following a rigorous and disciplined methodology for the procurement process will vastly increase the probability of a successful outcome. Maybe you already have a system that works well. Below is a summary outline of the system I have used and honed since my first large software procurement in 1996. If you are experienced at software procurement and implementation projects, this information may seem to be self-evident. However, considering the number of failed municipal software projects I have seen, the message hasn’t really gotten out yet. Notice that the RFP finally comes up in Step 8.
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or RFB (Request for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Site Visits – Customer and Vendor HQ
- Hold Software Demonstrations & Select a Solution
- Negotiate and execute the Contract
One of the primary objectives should always be the improvement of the quality of services in your organization and you should be aware of some of the project risks and political ramifications.
I cover the entire process here. Please feel free to e-mail me if you have comments or want to discuss software procurement in your organization. If you take a sensible and cautious approach using all due diligence, your project will certainly be a success.
If you want to talk about your project, send me an e-mail at jmorgan@e-volvellc.com.
Copyright © Jeffrey Morgan 2015, 2018
by 
Recent Comments