Search results: "project management" Page 3 of 5

Have People Had Enough Of Agile?

Agile Delivery

Photo Credit Shutterstock

If you work in a business that has anything to do with technology, you are familiar with Agile. You know the Agile I’m talking about. The kind where teams sit together and deliver software in increments. Seems everywhere you turn these days you hear about Agile. Along with Agile’s popularity has come a title wave of services. These services include coaching, training and certifications.

Consultancies have jumped on the Agile bandwagon big time. The other day I noticed a local consulting firm completely re-branded themselves. They are now the Agile experts. I was like wait, what? Like a year ago, they didn’t even provide IT consulting. Anyway, you get the point, Agile is the flavor of the moment and it’s everywhere.

Along with the over promotion and saturation of Agile, there has also been a mass influx of Agile gurus. These gurus scour the internet to prove their Agile knowledge is second to none. Agile to them has become a religion. They are quick to scold anyone blasphemous enough to challenge their Agile expertise. If you follow any Agile groups on LinkedIn, you’ve seen the ridiculous feuds. For sure the gurus will comment on this post to teach me the error of my ways.  Dealing with these gurus online is bad, but if you’ve had to work with them, it’s even worse.

So, between the obnoxious gurus and the commodification, I must ask, have people had enough of Agile? Is Agile software delivery like the glam hair metal of the 80s, and we’re at the point of Nirvana and grunge breaking onto the scene?  Keep in mind that as I ask this question, I’m a pro Agile guy. For many years, I studied and worked in both the Agile and traditional SDLC worlds, and today Agile is my preference. Although I’m a pro Agile, I’m concerned about what Agile has become.

To back up a bit, I started my career back in 2000 as a manual software tester, long before Agile exploded onto the scene. For years, I tested software for various organizations. Around 2008, I got introduced to Agile when I worked as a QA analyst on Scrum team. After time, I started working as an IT Project Manager and an Agile Scrum Master.

I studied everything I could on project management and on Agile delivery. I got my PMP and in business school I studied systems thinking and the theory of constraints. I attended Agile training, got a CSM (Certified Scrum Master) certification, and read every book I could on Agile.

Today, I still consult as an IT project/program manager or Agile Scrum Master. Although my preference is Agile, I’ll perform whatever the client role requires. Usually this means being a traditional project manager, an Agile Scrum Master, or a hybrid of both.

I have a real appreciation for Agile delivery. I found that the Scrum Master role coincides with two of my other passions, leadership and emotional intelligence. I love how Agile delivery is not only about writing code, but also about relationships and working together as a team.

As much as I’m a fan of Agile, I still think there is value in traditional project management. There are disciplines and processes that are tried and true in project management. We need to be careful not to write them off. Not all organizations are ready for Agile adoption, and that’s okay. I know that may sound odd coming from someone who is pro Agile, but if we are honest, Agile adoption is not easy. It isn’t as simple as attending a training. There are some great training services available, but often they have little effect.

All this leads me back to question, have people had enough of Agile? Am I, and pro Agile people like myself, part of the problem? Have we lost sight of the Agile Manifesto and become too dogmatic in our views, turning others off?

Soon Agile will morph into something else. New delivery frameworks will emerge, and so will new gurus. Whatever happens, it’s important we open ourselves up to not having all the answers, and we remain teachable. The main goal is that we continue to improve how we develop software and work together. To me, the Agile movement is a part of something bigger than certifications and gurus. It’s about working together to build quality products that provide value. What say you?

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Should a Scrum Master ever crack the whip?

Scrum Master

We know the Scrum Master role is different from a project manager. Scrum Masters are servant leaders, coaches and facilitators. Project managers are more aligned with command and control.

Does this mean that Scrum Masters should never crack the whip on the team?

Well, yes and no.

Just because Agile teams are self-organized, they sometimes still need to be pushed. Ideally the team will push themselves, but if that’s not happening then yes, the Scrum Master should put some pressure on the team. In Scrum, it’s usually the Product Owner who has some authority. Although the Scrum Master doesn’t have authority, they can vocalize the importance of getting work done (aka, crack the whip).

There are some misconceptions about Agile and Scrum when it comes to pressure. Some people think Scrum is a low pressure environment. Not true. In Scrum, they call iterations Sprints because teams are moving fast! There is pressure. There is also more visibility. Everyone can see what everyone else is working on in the Sprint. There is no hiding.

So, while cracking the whip usually aligns with project management, I do think it’s sometimes appropriate for Scrum Masters.

What are you thoughts?

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

 

2 huge reasons your Agile team struggles to be Agile

agile teams

In my recent post, problems with Scaled Agile, I discussed SAFe and the Agile mindset.

Aside from debating the value in SAFe, the post created good dialogue about how to foster an Agile mindset within teams. That is, how to help teams become more collaborative, open and trusting.

In my experience, teams often struggle adopting an Agile mindset for two obvious, yet overlooked reasons.

Reason 1 – The team consists of people who don’t like Agile

Think this sounds silly? I can’t tell you how many “Agile” teams I have worked with that had team members who wanted nothing to do with Agile. Not only were they not drinking the Agile Kool-Aid, they were down right opposed to it.

Management makes a big mistake when the put people who aren’t on board with Agile on Agile teams. The thinking is that team members will come around and learn to embrace Agile values. Of course, this doesn’t happen.

John Kotter, Harvard leadership professor, gives great advice on dealing with change resistors. His message is to not try to include them in the change effort. This means, go around them or get rid of them. This may sound harsh, but trying to include anti Agile people in Agile teams causes too much damage.

Managers – When you are forming Agile teams, make sure you bring on people who want to be on an Agile team. The challenge though, is vetting out the Agile imposters.

Reason 2 – People assume roles that do not align with their personality.

The classic example of this is when a traditional project manager takes on the Scrum Master role. A big misconception is that the Scrum Master and Project Manager roles are interchangeable. The truth is the two roles are different. The Scrum master role is about servant leadership. This is different from project management which is more about command and control.

Want to know if a Scrum Master is behaving more like a Project Manager? Attend the team daily scrum and you will find out. If the Scrum Master controls the meeting, they are in project management mode. The daily Scrum is a team meeting, it is not meant for each team member to provide status to the Scrum Master.

Some people who are great Project Managers make lousy Scrum Masters, and vice versa. Make sure you put people into a role that best aligns with their personality and strengths. If you don’t, good luck trying to change someones personality to fit a role.

To recap, if you want an Agile team that embraces Agile values, start by getting the right people on the team. Do not form a team with people who oppose Agile. Next, put people in roles that fit their personality. Do not expect people to change their personality to fit a role.

Like Collins says, get the right people on the bus, and in the right seats!

For more content like this, subscribe to the MacIsaac Consulting Blog.

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

 

 

 

 

Why Cash is King

Cash Flow

If you work in technology like me, you may not think there’s a need to focus much on finance. It is important though to understand the numbers, especially in project management.  In my next several blog posts I’m going to focus on financial management. To begin, let’s start with the green hard stuff, cash.

When it comes to cash and business, there are three things to know. The first is that cash is not the same as profit. The second is that most companies fail due to a shortage of cash flow. The third is that the cash statement provides valuable insight into a company’s situation. That last point is particularly important if you are planning to buy stock in a company. Warren Buffet might be the world’s greatest investor because he understands cash.

Cash is not the same as profit

Profit is the amount of revenue generated minus all expenses, what you have left is profit. So what is the difference between cash and profit? First cash doesn’t reflect money coming in through earned operating income. The cash may be coming in through loans or investors and that money doesn’t show up on an income statement.

Money from recorded profits isn’t received until some time after the transaction takes place. In an all cash transactions the funds will placed directly into the sellers account.  Small companies that are growing and creating profit, but not receiving the cash needed to keep up with expenses, run into trouble. This leads to the next topic which is that most companies fail due to a shortage of cash flow.

Most companies fail due to a shortage of cash flow

Profitable companies can go out of business if they don’t have enough cash. What happens is that they are continually waiting to receive cash to keep up with their expenses. An example would be as follows: Company A is a startup which over its first several months of business has recorded good revenue gains and large profits. The transactions for the products the company sells take 4-6 weeks for the funds to arrive. Due to the delay in receiving payments, the company does not have enough cash in the bank to cover the costs of operating expenses and growth. This ends up being a continual game of catch up with the actual cash behind the recorded profit. For most companies and startups it won’t be sustainable.

By reviewing a cash statement you can gain valuable insight into a company’s situation and where it might be headed

Income statements are complex and can be deceptive. The numbers can be manipulated by accountants to appear as though company is in better shape than it actually is. Most of the expenses on the statement haven’t been paid during the time of the statement.

Cash statements give an accurate view of how much cash was received and paid within a certain period. The cash flow statement can not be altered by the accountants like the income statement can be. Due to this, the cash statement gives great insights to investors because it paints a clear picture of how the company is doing.

In a sense the cash flow statement is a way of looking into a company’s bank account. The cash flow statement can provide valuable insight into a company’s future. If investment money is coming in, that may be an optimistic sign for the future. It could also mean that the company is selling stock to stay afloat. Looking at the cash flow statement may generate questions, but they are the right ones to be asking.

For more content like this, subscribe to the MacIsaac Consulting Blog.

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Why robots won’t provide as much value as people in the future

As we go about our daily busy lives, it’s easy to lose sight that we are in midst of a digital revolution. We take for granted what we are now doing through technology.  Using smart phones for Uber, tracking our daily activity through wearable devices, or speaking to an Amazon Echo are examples. It is incredible how fast technology has evolved. Yet, we are only in the infant stages of the digital revolution.

digital revolution

The digital revolution brings about great opportunities for business. This is particularly true for services using IoT (internet of things), Big Data, and Cloud based technologies. Expect that you will see an increase in AI (article intelligence), automation, and robots. Self driving cars, unmanned aircrafts, and smart devices have become a reality.

This advance in digital technology has left many in fear of losing jobs to robots, and for good reason. In a recent study done by the Korn Ferry Institute, 67 percent of executives said they would value technology more than people when looking at the next five years. The idea is that workers will be unnecessary due to robotics, automation and AI.

While there is no doubt that technology will replace many manual jobs, here’s the good news. Human capital will still hold the greatest value. Why? The main reason is that humans continue to gain knowledge and experience over time. In a sense, they appreciate in ways that machines cannot.

It is my position that as the world becomes more digital, we will see a greater demand for human capital.  It’s ironic but the advance in technology will provide a need for human connections. This means people will need skills based on strong emotional and social intelligence. This also holds true for technical leadership and project management positions.

Executives then need to value both human capital and technology. They need to find the right balance between the two. It would be a mistake to go all in on technology and lose sight of human capital importance. It seems most CEOs currently don’t grasp this. As CEOs face intense pressure to increase organizational performance, they focus on what they can measure. Robotics and automation give CEOs the comfort of figures and metrics that help them make projections about the future.

These metrics and data driven forecasts leave CEOs with a blind spot. What they don’t see, or can’t measure, are the human factors effect on performance. “Actually, the most important figures that one needs for management are unknown or unknowable, but successful management must nevertheless take account of them.” (Lloyd S. Nelson)

You can’t measure the positive effect of a warm and empathic interaction between a customer and an employee. The convenience and performance of machines could never replace our core need for social interaction.

So as you plan your strategy during this time of digital revolution, tap into what you already understand. People are the most valuable assets within an organization.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

References

http://static.kornferry.com/media/sidebar_downloads/KF1046_FOW_WP_AW_171116-4.pdf

http://www.bizjournals.com/twincities/news/news-wire/2016/11/18/a-robot-could-take-your-job-and-your-manager-might.html

 

System integration testing, a 6 step survival guide

system integration testing

So you’ve gotten through your planning, design, development and application testing. Everything looks good, the team feels confident, and the project is on track. There’s only one problem. Up until this point you’ve been looking at your code changes with tunnel vision. Application testing is like fixing a bike tire while it’s not connected to the bike. The real testing begins when the wheel gets reconnected to the bike. Once reconnected, then you’ll see the how the fixed tire works with all other parts of the bike.

I’ve been through many large software projects, both as a project manager and as a tester. Often the most difficult part of completing a software project is end to end system integration testing. This is particularly true if you’re not using an Agile model.

System integration testing is where the rubber meets the road. If you work for companies like Facebook, Spotify, or Twitter you are lucky. These companies use modern Agile software delivery methods that make integration testing less painful. Automation, DevOps, and continuous delivery is the way of the future.

Unfortunately most companies still build software the old fashion way. They create one huge pile of software then throw it over the fence to QA nearing project end. This leaves integration testing only a matter of weeks to complete and meet a tight deadline.

If you don’t do a great job planning for integration testing, you’ll be in for real trouble. If you do a great job planning, you’ll still most likely be in for some pain.

Here are 6 steps to help you survive system integration testing so you can be successful.

  1. Plan enough contingency time – This might be the most important point. Give the team enough time to do the test effort. If you know it takes 1-2 weeks just to get your environment and data working right, plan for that time. In system integration testing, many roadblocks occur. Data, configuration and environment issues can  block testing. Plan for the unexpected.
  2. Create test scenarios with the help of system experts – Once you know all the affected systems, find out who the technical experts are for each system. Then schedule white board meetings to draw out end to end flow test scenarios. The system experts will be invaluable helping you to write end to end scenarios.
  3. Get all your data setup in advance – There’s nothing more frustrating than finding out none of your data works on day 1 of testing. Setup your data in advance and check to see its setup right before you do your testing.
  4. Run connectivity tests – For large projects, take at least 1 week to test environment connections before the start of your SIT. Often companies use shared testing environments and configurations are always being changed. Make sure all your configurations and connections are setup. If you don’t do this, you’ll think you’re running into defects only to discover an application is pointing to the wrong environment.
  5. Use a war room – All throughout system integration testing you should have a room where all key resources sit together, all day. The key players usually consist of developers, testers, a PM, and system and environment experts. As soon as a test runs into an issue, a developer should be there to look into it immediately.
  6. Have a test lead manage the effort – Last but not least is having a good test lead. In my opinion, test leads have one of the most difficult jobs when it comes to managing integration testing. The job requires both testing expertise, project management skills, and tremendous grit. Often test leads have a lot of pressure put on them to meet deadlines. A good test lead will rise to the challenge.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Own Your WOW!

This morning I had the privilege of hearing keynote speaker Roshini  Rajkumar give a talk called  “Own Your WOW”.  The event was the Minnesota Business Magazine October Executive Breakfast. Roshini is a professional speaker and presence engineer. Her passionate, humorous, and audience engaging talk was fantastic!

As Roshini walked about giving her talk, to my surprise she approached me and asked what I did. Speaking in front of at least 80 business leaders, I uncomfortably told her I was technology consultant, specializing in project management. She pressed me by asking what makes me different from others in my field. I then began to relax and explained I’m an IT guy who also gets business, people and relationships. Luckily she was able to bring some authenticity out of me. This was an awkward moment for sure,  in front of a huge group, but she may have just helped me discover my Wow.

Roshini’s message is this, understand what makes you special and then own it! It’s not bragging or showing off to own the fact that you are great in a certain area. In fact, if you don’t own your wow, you’ll be lost in the crowd.

Below are just some of my key takeaways. Some of these pearls of wisdom came from audience members.

  • Exude confidence and passion in whatever it is that you rock at.
  • Have a positive attitude. An 80 year old gentleman in the audience said whenever he’s asked how he’s doing, regardless of how he feels, he says fantastic! This positive mindset then changes the way he feels for the better.
  • Transfer your enthusiasm to others. Particularly in sales, when you are enthusiastic, the enthusiasm transfers to your buyers.
  • Trust is key. You develop trust by wanting to use your talents to help others. After time, you will build a brand of trust and integrity.

Thanks Roshini for a wonderful talk!

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Top 10 influencers of the Agile software development movement

As a practitioner and student of Agile software development, I am fascinated by those who have influenced the Agile movement.

For fun, I have decided to put together my personal top 10 list of those who I believe have influenced what we refer to as Agile software development. Not only have they influenced Agile, most of them have put out bodies of work that will continue to educate future generations.

For all you Agile gurus out there, don’t freak out about who’s not on my list. You may have your own list which looks completely different. I know every time the the NFL puts out a top ten players list,  I’m usually in disagreement 🙂

Here we go…

10 -Kent Beck

 Kent Beck

Currently working for Facebook, Beck is the creator of Extreme Programming. He was one of the original contributors to the Agile Manifesto in 2001. He is a leading advocate for test driven development (TDD). Beck has published over 8 books on software development.

9 – Mary and Tom Poppendieck

Mary and Tom P

Mary and Tom are a package deal. I was fortunate enough to attend one of their workshops several years ago. Minnesota locals, the two have written together several books on lean software delivery. They helped bring lean production techniques to software development. Together they have had a big influence on the Agile movement.

8 – Jeff Sutherland

jeff_sutherland

One of my personal favorites, Sutherland is the co-creator of Scrum. A West Point graduate and pilot,  Jeff flew over a hundred missions in Vietnam. After his military carrer, Jeff got into software development. He was a doctor at the University of Colorodo school of medicine, and he helped write the Agile manifesto in 2001.

7 – Eliyahu Goldratt

Eliyahu Goldratt

Although his name may not be synonymous with software development, Goldratt has influenced the way we think about systems. Goldratt’s book “The Goal” is a required reading in almost every business school. He’s is known for his teachings on the theory of constraints (TOC) and the critical chain method.

6 – Ken Schwaber

ken_schwaber

The co-inventor of Scrum along with Sutherland, Schwaber is a prominent leader of the Agile movement. Ken has authored many books on Agile and Scrum. Ken founded Agile Alliance and Scrum Alliance, which created the Scrum master certification programs. Ken helped write the Agile manifesto in 2001.

5 – Jim Highsmith

Jim Highsmith

Jim has authored books on software development and Agile project management. He created the adaptive software development model. Jim is respected as a leader in the Agile software development movement. Jim won the Jolt award in 2000, and the Stevens award in 2005.

4 – Frederick Brooks

Frederick Brooks

Brooks is an American computer scientists widely known for his book “The Mythical Man-Month”. In his book he describes the lessons he learned while managing the development of IBMs System/360 family of computers. Brooks law states: “adding manpower to a late software project makes it later”.

3 – Taiichi Ohno

Taiichi

The father of the Toyota production system, Taiichi Ohno was the originator what we now refer to as lean. The processes and principles he put in place at Toyota had a huge influence on lean software development and Agile. Ohno claimed that he modeled the Toyota Production system after Ford, only he removed the waste.

2 – Henry Ford

Henry Ford

Ford is a fascinating American icon. He founded the ford motor company and helped create the assembly line production process. Not only did his assembly line process change the auto industry, it changed the world. Manufacturing would never be the same. What I admire the most about Ford was that he accomplished so much, and he did it all  through sheer determination.  Ford had little formal education, he didn’t graduate from High School.

1 – Edwards Deming

deming

My favorite quality guru, W. Edwards Deming. What I like the most about Deming was that he cared for the line worker. He championed pride in workmanship. He put the responsiblity on management to focus on the system. Along with a 14 point process for quality improvement, he created the PDCA (Plan, Do, Check, Act) method. The PDCA method is exactly what takes place during Scrum sprints (iterations). His processes and statistical control methods also revolutionized the Japanese auto industry.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

Don’t raise problems without solutions

microsoft-problems

Working in IT, whatever your role, you will encounter problems. Systems are down, deadlines are missed, code isn’t ready…etc. The list of problems you may face are endless. When faced with a problem, it’s easy to either escalate it or communicate the issue out to a wider audience. It’s harder to come up with solutions and take action on a path towards getting it resolved.

When you encounter problems, I suggest taking actions toward a solution before anything else. Once you have taken steps towards resolution, then communicate the issue to a wider audience. This way when you do communicate, you’re not just raising a problem, you are also bringing a solution. Chances are, your leadership team will look to you anyway to get the problem resolved.

Here’s the thing, people get frustrated when others bring them problems without solutions. When I worked in software QA and someone told me the system wasn’t working, I would begin a series of questions like…is the environment down? Have you reached out to the deployment team? Have you logged a defect? Have you done anything?

The point is, don’t just raise problems and expect others to do the work of getting it resolved. Go above and beyond. If you’re going to communicate an issue to leadership, tell them your plan to resolve it.  Even better, also tell them your plan to avoid it happening again in the future.

Now, there are sometimes when you should communicate issues before having a solution. If the house is on fire, everyone needs to know immediately. You can figure out cause and prevention later. But for most issues, you will have time to work on a solution before communicating to leadership.

For those of us who are project managers, managing and resolving problems is our job. When fires occur on our projects, it is our responsibility to get them put out. Project management is tough work. If you don’t enjoy taking the lead to resolve issues, while being the center point of communication, project management may not be for you. No matter how well you plan, your projects will hit turbulence.

For me, I actually enjoy the chaos that can come with project management. I like being the one to lead an “all hands on deck” war room fire drill. This doesn’t mean I don’t sometimes get stressed. I’ve been through enough projects now to know that dealing with problems is normal and part of the job.

Next time you encounter a problem, I challenge you to come up with solutions before you escalate. Start taking action to get the issue resolved. This way, your leadership team and stakeholders will know you are taking the lead.

Don’t just bring a problem, bring a solution.

For my next post, I’ll talk about how to not let someone else make their problem, your problem.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

Edwards Deming and quality control

W._Edwards_Deming

W. Edwards Deming was a quality theorist, statistician, author and management consultant. He was influential in the practice of quality management. Deming’s most urgent message was for management. He stressed that management create a system where each worker could do a good job and take pride in their work.

What is quality? The International Organization for Standardization (ISO9000) defines quality as “The degree to which a set of inherent characteristics fulfills requirements” (Project Management Institute, 2013, p.228). Quality is one of the most important factors for any business to be successful.

“Quality is more than just a statistical analysis tool for manufacturing lines. When done right, quality should encompass the entire enterprise” (Stevenson, 2009, p.406). An increase in quality results in better productivity, higher morale, and increased customer satisfaction.

Edwards Deming was a visionary who understood the importance of quality management.  His concepts helped Japan rise to become a world economic power.

History

Like most of the major contributors in the area of quality, Deming studied engineering. He would go on to get a PhD in mathematical physics from Yale in 1928. Deming was a professor of statistics at New York University’s graduate school of business. He later went to Japan after WWII to help improve their quality and productivity. He used statistical analysis and a systems approach towards quality.

Deming’s teachings and models were successful in Japan. To this day the Japanese give out an award for quality named the Deming prize. One of the causes for Deming’s popularity was his list of 14 points for quality. He was also an advocate of the Plan-Do-Check-Act (PDCA) cycle.

Deming lived from 1900 – 1993.  His theories had great success in Japan, but he didn’t have much popularity in the US until the 1980s. In the 80s he worked with American Automobile companies to help improve their quality.

Management and the system

One of Deming’s key messages was that the cause for poor quality was not the employees, it was the system. He emphasized that it was management’s responsibility to fix the system. “According to Deming, 85 percent of the quality problems on a project are attributable to the management environment and the system in which the team works” (Mulcahy, 2013, p. 297).

Appreciation for the system refers to everyone within a company working to achieve optimization. “Deming believed that knowledge comes from theory, and that learning cannot occur within an organization without a theory of knowledge” (Stevenson 2009, p 409).

Deming was an adversary of the annual performance review process within companies. He thought the arbitrary annual review process was managing by fear. He believed it robbed employees of their internal motivation. Deming believed managements greatest challenge was motivating workers to achieve a common goal.

The Plan Do Study Act (PDSA) Cycle

The concept of the PDSA cycle was introduced to Deming by Walter Shewhart of Bell Laboratories in New York. The first step in the process is to put together a plan by formulating a theory and creating success metrics. Next comes the execution of that plan (the Do step). Following execution is studying the results. The last step is to act based on the results found and put in place adjustments if needed.

The Five Deadly Diseases of Management

Edwards Deming recognized five deadly diseases of management which impede quality improvements. The five disease are as follows:

1.      Lack of constancy of purpose. This means that leadership needs to understand exactly why they are in business. They must have a clear mission that has a market for the future and is understood throughout the organization. Firms need to plan for the future and have a long term definition of goals.

2.      Short term thinking and emphasis on short term profits. Too much focus on quarterly dividends and raising the company stock. Not enough focus on quality and long term planning.

3.      The annual system of rating/performance review. The yearly employee review has a negative effect on long term planning as well as team work. Employees get bitter when they do not receive high performance ratings. The system is arbitrary, unjust and demoralizing to employees.

4.      Management that has no roots in the company. They lack knowledge and understanding of operational problems.

5.      Use of visible figures only for management. Management needs to  understand there are  unknowable figures.  Understand the importance of  the multiplying effect of a happy or unhappy customer (Deming, 1984).

14 Points for Quality

Perhaps the most well know of Edwards Deming’s teachings were his 14 points for management. Below are the 14 points as stated from the Deming Institute (https://www.deming.org):

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.

6. Institute training on the job.

7. Institute leadership (see Point 12 and Ch. 8). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company (see Ch. 3).

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

Eliminate work standards (quotas) on the factory floor. Substitute leadership.

Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.

12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective.

13. Institute a vigorous program of education and self-improvement.

14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

Stevenson, W. (2009). Operations Management, New York, NY: McGraw-Hill

Mulcahy, R. (2013) PMP Exam Prep, Minnetonka, MN: RMC Publications, Inc.

Project Management Institute (2013) Project Management Body Of Knowledge (5th ed.). Newtown Square, PA: Project Management Institute

Deming, E. (1984) Dr Deming – The Five Deadly Diseases [online Video]. Retrieved from the Deming Institute YouTube website: https://www.youtube.com/watch?v=ehMAwIHGN0Y

Deming, E. (1984) W. Edward Deming Quality Guru [online Video]. Retrieved from YouTube at https://www.youtube.com/watch?v=YQpY3lnljBE

Page 3 of 5

Powered by WordPress & Theme by Anders Norén