Tag: project management
Voodoo project management
Follow @evolvejsmorgan
In 1987, I was in the army and stationed at Camp Red Cloud in the Republic of Korea. One weekend morning, I had to track down a colleague whom I knew to be shacking up with one of the bar girls from our favorite hangout in Uijeongbu (의정부시). We’ll call him Sgt. Bob and we’ll call her Miss Kim. They were both really nice people and made a cute couple. Miss Kim answered the door and WHOOOAAA! Holy Cow! 아이고! I had only seen her at night, in a dimly lit dive bar wearing a kilo of makeup. The person who opened the apartment door that morning was much different in appearance.
I was reminded of that experience recently when I read the project charter for a troubled and failing software implementation. If bogus management mumbo jumbo actually got projects done, this undertaking would have been a fantastic success rather than drowning eight figures deep under water.
Beautiful planning documents
The project documentation was elaborate and beautiful. In 30 years of working on some pretty big projects, I have neither seen nor produced anything so impressive. It was all right out of PMBOK (the Project Management Body of Knowledge) and included all the pretentious, pseudo-business jargon one expects from graduates of third-rate business schools.
Discussing the project with management in the rarified environment of the C-suite, I could see all the butterflies, unicorns and balloons the executives were describing. They made it clear that any problems with the project were someone else’s fault. In the raw light of day, though, without the management makeover, the project started to look a lot more like Miss Kim did that Sunday morning.
Had this been a private-sector project, the PM and a couple of the executives would have been forced to change their LinkedIn headlines to “seeking new opportunities.” In the public sector, depending upon the organization, you can screw up big-time and generally still keep your six-figure job. You might even get promoted!
You’re fired!
No one involved in the grossly overstaffed and overbudget project had a clear vision of what the final product was supposed to look like or how it should function. As things continued to go wrong, more money and more unqualified people were thrown at the problems. There were no quality control mechanisms in place, and no one was really accountable for anything. It was all overseen and managed by people with PMP certifications. Typical public-sector IT, really. Firing the entire team was certainly advisable and justified, and many organizations would have taken that approach.
One problem was that the people leading the project really believed they had the required skills and knowledge, in spite of all the evidence to the contrary. After all, they had official-looking pieces of paper that said they were certified to manage projects. They thought they were brilliant managers and no one had ever told them anything different.
Do you think the $2.14 billion Affordable Care Act website was an anomaly? Nope! In smaller county and municipal government organizations, six- and seven-figure IT disasters aren’t uncommon. In larger municipalities and counties, eight-figure FUBARs aren’t rare. Once you get the state and federal level, the disasters can easily hit nine figures and the losses frequently end up buried in unmarked graves. Taxpayers rarely hear about these massive failures. The culprits get to keep their jobs and end up with generous defined-benefit retirements.
Paper professionals
Twenty years ago, one tech industry crisis was the “Paper MCSE” — someone with a Microsoft certification who had never touched a server. Project management seems to be in a similar crisis now. It seems that everyone is a PMP. One government project I have been following has received a few hundred million dollars in federal grant money, and they have been hiring lots of PMPs. All of them appear to be 12 or 13 years old, so I’m not clear on how they met the experience requirements for the certification.
Failure and the truth about management
One essential management skill not taught as part of the PMP or any other certification is recognizing and managing failure. The ability to identify failure, call it and transition to the success track is rare. In order to do that, one has to be able to say:
“I was wrong!
I managed that poorly!
I see where I went wrong and I will do it better next time.”
This almost never happens, especially in the public sector. Give it try. Practice saying it if it doesn’t come naturally. Familiarity with failure is a big part of success.
Unfortunately, ensuring the success of complex projects requires more than the creation of cool-looking documentation and checking off boxes as recommended in a handbook. Management of a complex project and a horde of stakeholders and vendors isn’t something you learn in a 35-hour class, and passing a multiple-choice test proves nothing about your ability to do it. If you have no idea what you’re doing, and no idea what you are trying to achieve, no methodology or framework will save you. One can’t just stick pins in a doll and expect something magical to happen.
This article was first published on cio.com at http://www.cio.com/article/3159118/project-management/voodoo-project-management.html
© Copyright Jeffrey Morgan, 2017
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