A client recently made a statement to me that roughly translated as I am concerned about the high cost of doing a quality job. Wow! Talk about not understanding the impact of quality. The organization was hemorrhaging from the consequences of low-quality work in a major software implementation. One of several root causes of that situation was a complete lack of quality management in the software build.
Unfortunately, they were contemplating the same ineffective approach the second time around. It was as if their failure had been caused by some mysterious external factor rather than poor management. If an enterprise software implementation is a disaster the first time around, using the same management approach will produce the very same outcome every time thereafter. Quality must be envisioned and planned from inception. “Once the plans are part way in place, it is too late to build quality into a product.” (Deming, W. Edwards. Out of the Crisis (p. 212). The MIT Press. Kindle Edition.)
High-quality work is expensive, but you only pay for it once. Low-quality work is unaffordable, because your organization will pay the price forever.
Quality is universal and interdisciplinary
I found my first really good piano teacher when I was 16 and the fundamentals of quality I learned from her still resonate intensely nearly 40 years later. I have yet to master and live up to the standards she taught me in the late 1970s. Over the ensuing years, I learned a great deal from many other fine teachers and mentors, but none instilled in me the work ethic and pursuit of perfection that Bella did.
Bella had been a student of Isabelle Vengerova at the Curtis Institute of Music along with many of the finest musicians of the 20th century. Every week for several years, Bella and Max (her English bulldog) put me through a grueling workout that included a devastating blend of castigation, insults and humiliation. In our second lesson, she told me, “My god, I do believe that is the worst thing I have ever heard.”
I kept going back for more because the value received was far greater than the pain inflicted. She was a chain-smoker and bore a striking resemblance to Max — they were both adorable. Neither she nor Max were proponents of the namby pamby, “I’m OK, you’re OK” coaching and management style that rules today’s world. I had to work my ass off to get a minuscule compliment, and her brutal honesty toughened me up considerably.
Bella taught her students to seek perfection by relentlessly focusing on fundamentals while adhering to the highest standards of quality. “It’s not what you play; it’s how well you play it” she taught.
Most of the managers I encounter could learn a great deal from Bella’s approach to quality management, but only if they could learn to tolerate brutal honesty and the deep introspection that it should trigger. Too much management is based on quantity rather than quality.
Consequences for delivering poor quality
A while back, I had a contract with a generally well-managed company that was 300% over budget on its ERP implementation. The executive team quickly grasped the root cause of this problem: The CIO had championed the project, established business requirements, and managed the implementation. It was his responsibility to ensure that quality goals were met. That company believed in accountability so the CIO decided it was time to retire.
Quality is inclusive
One of the things I like about an agile approach for business process and software development is the inclusion of end users from the very beginning. Agile recognizes that quality is defined by the customer rather than by specifications. Customer-centric quality control is built into the process.
End user participation and input is absolutely essential to creation and validation of quality during the process of building a system, whether it is a commercial product or custom-developed software. Some of you are probably saying, “Jeff, that’s self-evident. Everyone already knows this.”
Unfortunately, everyone does not. Every major enterprise project failure I have studied over the last 20 years has largely excluded end users from the development and quality validation processes. The application was dumped on the plate of the end user with an attitude that said Here it is; you had better like it. In those failed projects, quality was defined by a developer or by managers who would never use the product. Consequently, there is a direct correlation between project failure and exclusion of end users, at least in my experience.
In many of these failures, a traditional project management approach had also been used. Maybe the result was due to the practitioners rather than the approach, though. There is no reason why one can’t modify a waterfall project management approach to include end user quality validation. The only thing likely to get in the way is the ego of the project manager.
Quality creates a chain reaction
I have seen the results of brilliant quality management in many organizations. Outstanding quality is visible when you walk in the door, and you can hear it through a phone in the voice of a receptionist. Every employee in the organization radiates excellence, and the entire organization is just wet and dripping with exceptional quality. One organization that immediately comes to mind is the Memorial Sloan Kettering Cancer Center in Manhattan, but many organizations do it fantastically well.
When you do it right, the quest for quality becomes part of your organizational culture. You can implement quality in your department, but you’ll find it easier if you have executive support.
Improvement of quality transfers waste of man-hours and of machine-time into the manufacture of good product and better service. The result is a chain reaction — lower costs, better competitive position, happier people on the job, jobs, and more jobs.(Deming, W. Edwards. Out of the Crisis (p. 2). The MIT Press. Kindle Edition.)
How about your organization? Is it slick and shiny with quality? Or dingy and rundown like a barracks in a Soviet gulag?
If you would like to read more about quality, try the following works:
Out of the Crisis, by W. Edwards Deming.
Managerial Breakthrough, by Joseph M. Juran.
© Copyright Jeffrey Morgan, 2016
This article first appeared on CIO.COM at http://www.cio.com/article/3131977/leadership-management/we-cant-afford-quality.htmlby
What the hell do all these IT people do all day anyway?” That’s a great question often posed by staff members, CEOs, CFOs and line-of-business managers. As a senior IT executive or manager, can you answer that question?
I often see IT staffers engaged in ridiculous pursuits that provide no value to an organization — printing business cards, acting as intermediaries for support calls to external vendors, repairing equipment that is under a service contract, and generating reports that should be created by end users. Moreover, I see too many menial, repetitive tasks like patch management being performed by expensive humans rather than by automated systems. Many IT directors either don’t recognize the dysfunction or see it as a way of keeping their overstaffed empires intact.
Even worse, IT staff members often engage in activities for which they are not even remotely qualified, but which they insist on performing because of some misplaced DIY (do it yourself) philosophy. Such activities are often part of what I call a wild-west management style where IT staff members decide for themselves which activities are of value to the organization. I recently had an encounter in which an IT minion told me that TCO (total cost of ownership) information I was requesting as part of an audit was “not going to provide value to the organization.” Huh!
What is important to your organization?
Services that are valuable to one organization may be of little or no value to another. Establishing what services will provide value to your organization is a critical business activity in which you and your executive leadership team should be fully engaged. These decisions shouldn’t be left to the whims of minions. Unfortunately, this sort of strategic planning occurs in few organizations. If you are working for one of the majority of organizations not following any best practices for IT service delivery, this conversation with your leadership is even more important. There is really no such thing as an IT problem, but management issues abound.
As a manager, one of your primary functions should be to “make resources productive” (as Peter Drucker wrote in The Practice of Management). Are you doing that? Can you instantly produce reports and metrics demonstrating that your IT operation is delivering real business value to your customers? Can you summarize exactly what services and value your IT operation provides? “Serving the needs of my customers” isn’t a good enough answer. Trying to be everything to everyone generally results in being useless to everyone.
The biggest risk to an internal IT operation isn’t external contractors; it is poor customer service. Let’s discuss how to reduce that risk.
Solutions: Start with the basics
Do you know what your staff members are working on? Are they using a clearly defined service catalog, adhering to a service-level agreement (SLA) and using a professional services automation (PSA) system? These are basic governance documents and operational tools that should be in deployed in even the smallest IT operations but they are often absent even in large, well-funded IT organizations. Indeed, smaller organizations with scarce resources would benefit most from these tools.
Instituting just a few of the basics will dramatically improve your IT service operations. Let’s take a look at three best practices you should be using. We can think of them as a poor man’s ITIL (IT Infrastructure Library), but you don’t need a full-blown ITIL implementation to improve the efficiency of your operations. Use common sense, a structured approach and a cycle of continuous improvement. The perfect time to begin is right now!
A service catalog is “an organized and curated collection of any and all business and information-technology-related services that can be performed, by, for or within an enterprise.” (Wikipedia)
The catalog should be developed with your executive leadership so a clear and universal understanding of the services you are providing is available to your customers. Which services are provided internally and which will be performed by external contractors? How much do they cost? When are they available? There is a downside to service catalogs, but this can be managed.
Focus on high-value services that you can realistically support. Strive for quality rather than quantity. Doing a few things well is preferable to doing many things poorly.
SLAs are often treated as requirements for external vendors, but why shouldn’t internal service providers be held to the same standards as external ones? CIO provides good discussions here, here and here.
Once you have an SLA in place, it must be enforced. You are the manager, so do your job and start managing.
An overarching problem in our industry is that end users often complain that IT is not responsive to their requests for service. Is that really true? Did they really report a problem to IT or did they just go home and tell their cat? Or did they casually mention their problem in the break room? All encounters between IT personnel and end users should be fully documented in a highly automated PSA system that has audit trails and escalation policies.
Lack of a PSA system is my biggest IT pet peeve. There is no excuse for not having such a system, and they are downright cheap compared to the cost of IT labor. In an IT assessment or audit, the lack of an auditable system to manage service requests can bury you — the vulnerable CIO or IT director. The reports and data from such a system can prove what a super manager you are. Or they can demonstrate your total incompetence.
You will incorporate your catalog of services and SLA into your PSA system.
It’s no accident
Providing superb, high-value IT customer service doesn’t happen by accident. By following a few relatively simple steps, and having discussions with your executive team, you can dramatically improve the quality of your operations.
© Copyright Jeffrey Morgan, 2016
This article was first published at http://www.cio.com/article/3126384/leadership-management/what-is-the-biggest-threat-to-internal-it-departments.html on CIO.COM.by
How can you distinguish a green CIO from a seasoned one? That is simple! The newly minted CIO will agree to manage a line-of-business (LOB) project.
A colleague recently related this story to me: “When our hospital’s executive team held a meeting to announce they were pursuing a new EMR (electronic medical records) solution, the CIO immediately stood up and said, ‘We will gladly provide IT support, guidance and leadership, but this is a line-of-business project and an LOB expert should lead the project.’” That’s a savvy CIO! He will still have a job if the project sinks into the cold, dark abyss of failed enterprise initiatives.
Line-of-business projects are shoals no CIO should ever enter unless he or she is an expert in that specific business. Whether you are a hopeless ingénue or a good captain ordered to enter those dangerous waters, you’ll need a really detailed map that you may have to build yourself. That map includes a deep understanding of specific business requirements, workflow, expertise in industry best practices, regulatory compliance and much more. If you scrape your hull against just one hidden iceberg, you might end up going down with the ship.
Assessing business requirements
Do you have trusted staff members qualified to identify and analyze all the business requirements for such a project? I’m not sure what qualifies someone to perform this type of work. I learned it from 15 years of studying composition and music theory that included five years of graduate school. If you analyze and account for every note in hundreds of sonatas and symphonies, complex business processes will seem simple by comparison.
Learning a new business process is a lot like learning a new piece of music: You immerse yourself in it for days, weeks, months — whatever it takes. You examine the processes from every perspective, map out the requirements and isolate the difficulties. Switch views between the micro and the macro constantly. You should always be thinking about what the end product will ultimately look like from the beginning of the project.
I’ve seen programmers, engineers, business types, clinicians, sociologists and others do it well. I have been less than impressed with IT staff performing these tasks, but maybe I am jaded from 20 years of salvaging or condemning failed enterprise projects. Often, those projects were unsuccessful because they were approached from an IT perspective rather than from a line of business point of view. In many of those projects, end user concerns were marginalized and invalidated in favor of some nebulous IT agenda. In the finales, the end users always got their revenge.
Beware of dragons
There’s another reason why a CIO might volunteer to manage an LOB project — empire building. This is another characteristic that distinguishes the seasoned CIO from the guppy. Successful CIOs drive in their lane. They follow my Nana’s sage advice: “Mind your own beeswax.”
I don’t understand what drives some IT executives to get involved in “improving” business processes in another department or division, and these attentions are often unwelcome in the enterprise. Time and again, these activities are driven by the CIO’s failure to manage his or her own operations well. “Nothing to see here folks, look over there.” If you have time to worry about other people’s jobs and activities, you either don’t have enough to do or you’re doing it poorly.
Should you still have aspirations for building an empire, do some research by binge-watching a few seasons of Game of Thrones. If you have the required analytical skills, and the project turns out to be a success, you may be knighted for your excellent work. However, when things go wrong, aspiring kings and emperors are poisoned, lose their heads or end up uttering “Et tu, Brute?” as they are ushered into a premature retirement. That unassuming line of business executive you stepped on might have a few dragons at her disposal.
Empire building is bad for business and bad for everyone in the organization. It creates conflicts and resentments and it can lead to massive project failures.
The root cause of enterprise project failure
Why do enterprise and line-of-business projects so often fail? Although it has been written about for 2,500 years by everyone from Aeschylus to Tom Wolfe, the answer isn’t taught in business school. We all learned about the root cause of project failure in high school English class but most of us seem to have forgotten those important lessons. Or perhaps we have never bothered to apply metaphors learned so long ago to our careers.
At the root of it, projects fail because of hubris. The hubris I have seen over the years from CIOs, CEOs and CFOs who were overseeing failed projects has always been incredible to behold. Overconfident and underprepared, they set sail without a compass, a map or enough provisions for the journey. They left port trying to catch a whale with a crew that only knew how to catch minnows. They cast off without knowing where they were going, and they are always astonished when they end up lost at sea. The next time you are asked to manage an LOB project, don’t make the same mistakes.
This was first published on CIO.COM atby
By Jeffrey Morgan
About twenty percent of people are really good or pretty good at what they do. The other eighty percent are mediocre to poor. This rule unfortunately works across all professions – doctors, attorneys, bartenders, auto mechanics, IT people, grocery store clerks, etc. When I need a professional, especially a doctor or lawyer, I try to choose from those in the twenty percent. I really learned this lesson the hard way during my divorce. I only got the right attorney on the fifth try.
If you are a manager or supervisor, you are stuck with this reality.
What puts people in the top 20% or the bottom 80%? Talent, intelligence and aptitude are all part of the equation but these factors only partially account for great work output. Work ethic and attitude are the factors that really matter.
My parents and many teachers tried to teach me about work ethic in my youth but I didn’t really learn the lesson until I was in the army. Almost thirty years later I still remember my moment of work ethic epiphany. My platoon members and I were all in our Quonset hut at Camp Red Cloud in the Republic of Korea cleaning weapons and I clearly remember Sergeant C talking about work ethic. Always do the best job you can do regardless of whether it is cleaning weapons, cleaning the latrines or performing your mission in the field.
This was only a few days after he went on an epic rampage. He had been away for a few days and when he came back and took a look around, there were a few problems. Someone had left a broom out in the motor pool and someone from another platoon had borrowed a tire from one of our Hummers. There were a couple of other minor infractions. This triggered a screaming virtuoso performance in denigration and excoriation in the most impressively profanity filled reaming I have ever received. We all walked away from the 30 minute (seemed like hours) reaming thoroughly demoralized and totally ashamed. But it made us all better people. It was a lesson that has shaped my life ever since.
Sergeant C was trying to drag us all into the 20% and wouldn’t tolerate anyone in his platoon being part of the 80%. In the current climate of PC and positive reinforcement, Sergeant C’s management style probably wouldn’t be tolerated but it was certainly effective. Giving out gold stars for shoddy performance does no one any good.
If you are a manager, you are stuck with your own staff of 20% vs. 80%, but you can certainly influence those in the 80% to perform better. If Sergeant C could do it, so can you. Have a comment? Need help in improving the quality of output in your organization? Send me an e-mail at firstname.lastname@example.org.
Copyright © Jeffrey Morgan 2016by
Reduce the Cost of your operations by improving Quality: William Edwards Deming and Quality Management in a Public Sector Organization
If you improve the quality of your product or service, productivity is automatically increased and costs go down.
I first learned about W.E. Deming while I was in graduate school and also working in the Product Engineering department of a Fortune 500 company. At the time, the company was implementing Total Quality Management (TQM) and I was really impressed by the scope of changes the company was employing in order to improve its product quality.
Deming’s approach to quality and productivity is widely used in manufacturing, but not so well recognized in the Public Sector where I do a lot of my work. However, applying Deming’s concepts and methods to Public Sector organizations can create a profound improvement in the quality of that service while automatically improving productivity and lowering costs.
Combine with a Business Process Assessment
Any time you are working on a business project such as procurement of a new software product, a perfect opportunity to review and streamline all your business processes presents itself. In fact, this may be the only opportunity you have to make improvements in the delivery and efficiency of services for the next decade or two if your organization functions like many in the Public Sector do. There is no software product that will magically improve your business processes – you must analyze the business processes and build your new, improved processes into your new system.
A business process assessment in advance of your upcoming software acquisition can identify the bottlenecks in your business processes that create inefficiencies in your operations. I can provide a few of the many examples that I have encountered with my clients. In one organization, I found a 10-step process for recording of revenue that resulted in a 3 month delay in that revenue being booked. This process should have consisted of a single step with instant booking of the revenue. While doing a business process review in another organization, my client identified a 17-step process that resulted in a lengthy delay in booking revenue and sometimes in the total loss of that revenue. Again, that process should have consisted of a single step.
Is your organization plagued with bureaucratic processes like those mentioned above? No one knows why the process is that way and no one can remember when it started, but “We’ve just always done it that way.” This is the reason why I do a bottom-up business process assessment. There is no way to capture these processes unless you interview and observe the people who actually do the work. The gulf between Minion and Management is vast and Management often has no idea of what the exact processes are in various departments and functions of a large organization.
Once you identify all of these process bottlenecks, you will want to make sure you build the new, more logical and efficient process into your new software system. Unfortunately, many organizations do what a colleague of mine describes as “recreating all the dysfunctional processes in the new system.” If you are going to take that approach, why bother with a new system?
If you want to read more about improving quality and productivity while lowering costs, try Out of the Crisis by William Edwards Deming (1982, Massachusetts Institute of Technology, Center for Advanced Educational Services, Cambridge, Massachusetts). If you want to discuss methods for increasing the quality of your services, e-mail me at email@example.com.
Copyright © Jeffrey Morgan 2015by
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.
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.
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?
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
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 firstname.lastname@example.org.
Copyright © Jeffrey Morgan 2015, 2018